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ABSTRACT 


A systems analysis of a comouter system to suoport the STAR 
war agaming model 1s presented. The war game is described 
and the user's objectives are defined. Four conceptual 
methods for tmolementina the user's objectives are oresented 
and a preferred solution its chosene The characteristics of 
the preferred solution that are necesSary to meet the user's 
objectives are described. Further software needed oe) 
imolement the objectives is oriefly discussed. The code for 
the current mode] iS analyzed and a Summary presented. 
Conclusions from this systems analysis are derived and 


future research areas are identified. 
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I. INTRODUCTION 


A computer simulation 1s the representation of a 
mathematical model in a manner that allows the user to 
examine the system being modeled and gain further insiaqnht 
into the inner workings of the system. Typically, 
simulations fall into five classes: the oresentation. of 
unobservable phenomena, ooerator training modelssr gaming 
models, design tools and models of systems with factors that 
preclude experimentation on the system itself [Rahe 19/72). 

Modern computers and graphics terminals have removed the 
last barriers that previously: dictated alledigital 
Simulations. These terminals can de used as exceptionally 
fast and versatile output devices. The comouter may be 
equipoed with a grapnical ineut device such aS a araphic 
tablet enabling the system to be used as a drafting device 
with unique orooverties (Newman and Sproul! 1973). 

The comouter system intended for use should provide ons 
line, hands=on hiqh=-sceed comoutation with excellent 
disolays and interfaces to externa] hardware. The 
application oof aqraphical Support to war gaming adds a 
Gimension previously not available to the modeler. The 
Capability to visually monitor the simulation durina 
execution provides insight into the system being modeled 
that tabular results obtained after the fact can never hope 


to attain. Interactive programming allows the develooment 





of applications which can interact with a user and enabie 
him to control the functions oerformed and the data operated 
on by the program. The modeler may now interactively 
participate in the simulation and at critical times’ make 
decisions that will create changes in the outcome of the 
simulation. 

One important facet of interactive proaramming is the 
aspect of man=computer symbiosis. By achieving a very close 
coupling between the human and the comouter,the comouter may 
facilitate formulative thinking and allow the human member 
of the oartnershio to particioate in makina decisions) and 
controlling comolex situations without inflexible dependence 
On opredetermined orograms [Licklider 1960]. 

Any system devised to attain such an interactive 
simulation system with graphical support should not be 
hastily thrown together. "Add-on" supoort tends to overly 
complicate and, reduce the efficiency of the existina system. 
For any system, the principles o f simplicity and 
effectiveness are essential to the usefulness of the system. 
These two principles often comoete with each other (Smith 
770). im—thism lant, 1 1S Ceitical that to SUOpOort any 
existing or planned system, a careful systems analysis. and 
design must be the first step toward imolementing that 
Support. This added effort should result in an efficient, 
effective system while maintaining maximum flexibility and 
smolicity. In the rush to implement a major system, the 


emphasis is generally olaced on the application with little 





considerstion given the human factors when the interface 
between man and his. Program 1s implemented. Human interface 
is desirable at setup time when there are many disolays, 
options and oarameters for auser to control. If he is an 
experienced user he does not want to be forced to cycle 
through al] the ootions. The user desires only enough 
promoting information to chanae those options necessary to 
setuo and execute his rune No matter how well a system 
performs, it will be little used if it js) Ort ticiy!] t 26) 
setup. The user must be considered first and effective 
man=machine interface dialoaue we ee become a major 
consideration, as important as the apolication itself. 

The process of extending an existing war game to include 
interactive functions is so comolex that crogrammina 
productivity techniques must be planned and employed from 
the onset. These modern techniques have proven to be 
Meecessful in control of software orojects. Such techniques 
as structured designer too=down designer too~down proarammina, 
modularization, structured oOrogramming and walkthroughs, 
chief orogrammer team concepts and a scheduling methodology 
will be crucial to the develooment and maintenance of = an 
acceptable model. 

This study considers all possible software concepts = and 
explores their apolicability to the model. Some of these 
that could prove to be useful tools are: database management 


Systems, SIMSCRIPT, graphic support lanauages and either 


general puroose or tailored versions of operating systems. 





Various programming lanauages lend themselves to war 
gaming. The advantages of a high level language are wel] 
established and their usage is particularly significant rn 
the area of programmer productivity. S8ecause each of these 
language instructions translates into 10-20 lines o f 
documented code, the daily productivity of the programmer 15 
increased at least three fold. Jhis increase has been 
demonstrated in numerous studies [Brooks 1975]. High level 
languages also contribute to lower application maintenance 
costs, improved documentation and design through their 
ability to allow selfsdocumentina variable names, new 
constructs and easier imolementation of alaorithms (stack 
and queue manipulation for examole). 

SIMSCRIPT is an examole of ae high level language 
especially developed for simulations. The tnternal functions 
of SIMSCRIPT such as the event scheduling, queue 
manipulation .and system defined variables enhance the 
desirability for using it. FORTRAN subroutines can be 
readily caljiled from the lanauage allowing proaram efficiency 
to increase by emoloying critical code in the form. of 
FORTRAN subroutines. The current version of SIMSCRIPT II.5 
waS written in SIMSCRIPT II.5. This fact demonstrates the 
versatility of the language. In the last several years 
certain develooments have imoroved the efficiency of 
SIMSCRIPT. Among these developments was the move from the 
generation of FORTRAN intermediate code to direct generation 


of machine code. Additionally, the number of steos required 
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to compile, linkwedit and execute a SIMSCRIPT program was 
reduced, shortening compilation time. 

This systems analysis parallels most systems analysis 
procedures but addresses the question, "What resources do I 
need to provide the desired capabilities given only the 
Semstraint of using SIMSCRIPT I1.5 as a base simulation 
language" versus “How can I design this system to run on a 
Barticular comouter". This is Warsi dered the appropriate 
approach to designing a system which truly meets the needs 


of the combat modeling community. Figure 1.1 depicts the 


systems analysis procedures followed. 
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The first and key element of this Systems analysis study 
was the identification of the user's objectives. Without 
this critical action the entire study would have been 
meaningless. The objectives” fell into the three general 
areas of graphical display support, simulation of the battle 
area and the capability to determine the status of the 
battle or any of the components of the battle at any desired 
instant of time during the ET Se TGR 

Once the user's objectives were determined,s, the next 
steo was to select a set of general performance criteria. 
Performance criteria are the key to measuring the degree of 
success in attaining the objectives of the user. System 
performance measures must be considered to oroduce an 
efficient and effective system for the entire life-cycle. 
The system must possess the ability to reflect changes mn 
both friendly and enemy force structures and tactics. The 
data reflected by the disolay devices must be current at the 
time of Apes iSy: This could mean that the simulation would 
have to be halted until a signal 1$ generated by the 
completion of the display. The quality of the data base 
will be reflected by the level of data integrity needed. Tne 
Size of the data base must be such that only necessary data 
1tems be stored. Any abuse of this will surface in the 
response time for any display invoked and the overall amount 
of secondary storage required for the data base. The system 


was designed with growth in mind so that additional 


Capabilities may be accommodated as new technology develoos. 


le 





As tactics and force structures change, the system must be 
capable of easily absorbing these needed changes. Response 
time, another performance measure, 18S considered to be from 
the time a user depresses a carriage return after a display 
request until that request is satisfied. From other studies 
{Sutherland 1966] response times of greater than 10 seconds 
are not desirable since the human mind will become impatient 
after such a !ong waiting period. f good response time 1s 


usually three to five seconds. 


Alternative designs were conceiveds each possessing the 


capability to provide all of the desired functions 
identified as user objectives within the performance 
criteria established. Alternative conceotual designs are 
defined as concepts arrived at through "dreaming" with 


objectives and restrictions in mind. In order to attempt to 
capture the latest hardware and software capabilities and 
Philosophys and incorporate them into this system, a certain 
amount of ee Pes research was conducted in the areas of 
Simulation, interactive Graphics, database design = and 
implementations, operating systems and systems analysis~ and 
agesign. 

After the list of designs was consolidated into general 
conceptsr, each conceptual desian was evaluated to insure 
that the design under consideration met the objectives. The 
advantages and disadvantages of each alternative were 


determined. Pris reduced the list iO Cn) | ¥ feasibile 


solutions to the oroblem. 
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Eneoter Ii briefly discusses the history of war gaming, 
the evolution of . STAR, a current description of STAR and 
proposed enhancements with the support required to achieve 
them. This final version of STAR is the entire reason for 
this thesis, that 1s- the design of a system to reach this 
goal. 

Chapter III discusses the alternative approaches to the 
design of a support system for STAR. The alternatives 
include a database management system, an operating system, a 
distributed system and graohical routines imbedded in the 
simulation program. These alternatives are described = and 
evaluated as to their individual capability to imolement the 
system. A prefered solution was then chosen. 

Chapter IV continues with the analysis of the operatina 
system needed to support the solution from chapter III. The 
basic features needed to support STAR are descrived = and 
examples of their use are given. The modules of STAR not 
previously written are outlined to aive guidance in future 
development activity. 

Chapter V presents the results of the analysis of the 
Current version of STAR. This chaoter summarizes tne 
findings of the analysis and presents modifications and 
recommendations that will lessen the storage requirements 
for STAR while speeding up the execution of the model. 

Chapter VI contains conclusions from this thesis. and 


recommends further courses of action to achieve the desired 


end product. 
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Il. BACKGROUND 


A. HISTORY OF WAR GAMES 

War games are nearly as old as organized warfare itself. 
Evidence has been uncovered that indicates the use of games 
to simulate war In ancient Payor mipmeeress in war gaming 1s 
marked by a series of improvements in support techniques 
available to the user. 

During the latter half of the eighteenth century the 
Prussians developed an increased emphasis on warfare as a 
branch of applied mathematics. In 1780, Helwigr Master of 
the Pages for the Duke of Brunswick, invented a game quite 
similar to the modern commercial war aame. The qame used a 
modified chessboard. Terrain was represented by using 
combinations of 1666 small squares tinted in various colors. 
These small Squares were grouped onto the boaro as terrain 
features. In 1795 Georg Vinturinus modified the game by 
constructing a map board of an actual piece of terrain. 

In 1811 von ReisSwitzZr the Prussian War Counselor. at 
Breslau, transferred the war game to a sand table with 
terrain modeled in sand to a scale of 1:2373. In 1824 Army 
Lieutenant von Reisswitz, Jr. modified his father's qame by 
transferring the game to a realistic manpwlike chart with a 
scale of 1:8000. An umpire, detailed ruless and ocrobability 
tadDles were also introduced by von Reisswitz, Jr. The size 


o f the game was limited to approximately four square miles 
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of ground. The umpire not only monitored the play of the 
game for compliance with the rules but also imposed two 
minute time slices tin the olayinq of the game. In this 
manner the game could be stopped, as desired, and a 
particular two minute round could be studied in detail. 

Further improvements occured during the ninteenth 
century. In 1866 Lieutenant Wm, McC. Little suggested a 
game called “Naval War Game" that employed oblackboards, 
sheets of paper or chartSs, or maps placed on tables to 
illustrate terrain. At about this same time celluloid sheets 
or overlays were introduced. Information drawn on these 
overlays was saved as a historical record that could be 
analyzed at a later date. This idea of overlays is 
attributed to the Naval War College. 

Farly in the twentieth centuryrs, new maps predared 
especially for map maneuvers showed larace tracts of actual 
terrain. The oldest map of American terrain made expressly 
for mao maneuvers dates from 1906. This map of Fort 
Leavenworth, Kansas ineludes a tract approximately four 
miles in width by six miles in length with a scale of 1:5280 
and a contour interval of ten feet (JCS 1969]. 

In the post AWWeII era, the military use of war games 
became increasingly sophisticated and widespread. 
Sophistication is achieved through increasing comouter 
technology. The computer allows large amounts of data to be 
Stored and manioulated without tedious bookkeeping on the 


part of the user. There 1S some debate over the usefulness 
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of such computer simulations. The amount of data generated 
igs sO great that it can overwhelm the user, thereby 
undermining the very reason for the simulation. 

Modern computer war games have seen evolution similar to 
manual games. One oparallel development is in the terrain 
model associated with the game. Early aames used fiat 
(imaginary) terrain. Terrain advanced to idealized, easily 
constructed models that represented no identifiable terrain. 
The next step was to represent real terrain through the use 
of digitization at the expense of storage. The latest 
oreakthrough 1s 6tthe.6UuSe.)—6UlCOof parametric terrain capable of 
modeling any real terrain ina size never before imaaqined 


(Needles 1976]. 


PeevVOLUTION OF SIMULATION OF TACTICAL ALTERNATIVE RESPONSES 
(STAR) 

A niin cant effort is currently underway at the Nava} 
Postgraduate School to develop a mid-=resolution combined 
arms model to determine both hardware and traininaq measures 
of effectiveness. One of the orimary goals of the model is 
to achieve an acceptable level of resolution while assurina 
that the model inouts and interactions are understood by the 
military decision-maker. 

Five theses completed over the last two years form a 
basis for continuing the model develooment. A parametric 


terrain model was developed to orovide a continuous macro- 


terrain reoresentation. This reoresentation has several 


Ie 





advantages over the classical approach of digitized terrain. 
Linewofesight computations are made directly from 
mathematical relationships as opposed to the time-consuming 
iterative process required with digital terrain. Mobdility 
is truly continuously as opposed to piecewise linear 
techniques used for digitized terrain. Terrain can be 
considered as a parameter of the combined arms analysis as 
opposed to ae given. By appropriate selection of itnout 
parameters, any real section of terrain can be closely 
approximated by the oarametric terrain model. Any size 
terrain sector can be easily generated without the storage 
constraints of digital terrain. A dynamic smoke module has 
been developed and operated in the oarametric terrain model. 

After development of the terrain model, two theses were 
devoted to atarget servicing evaluation of blue artillery 
against a red ground threat. The result of this effort was a 


working model programmed in SIMSCRIPT which provides dynamic 


reoresentation of the artillery missions down to the 
Individual element level. This model forms the basis for 
future enhancements of the combined arms model. An 


ammunition supoly model was developed to represent the 
effects of such parameters as interdictive enemy fire, RAM= 
D, truck trips oer day to the ammunition supply points truck 
replenishment rate, etcer On the number of rounds available 
to the combat vehicles over any suStained combat period. 
Current efforts are underway to incoroorate' tworwsided 


Qround and artillery, with other systems as close air 
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support, minefields, cannon launched guided projectiles, 
advanced attack helicopters, air defense, etc. These 
enhancements will be made to the blue battalion versus” red 
regiment model. In additions, a dynamic ammunition resupoly 


model 1s being developed. 


meCURRENT DESCRIPTION OF STAR 

The structure of STAR is truly hRierarchial in that it 1s 
not confined to any soecific unit size or configuration. The 
Barent=-child set structure of SIMSCRIPT, coupled with the 
flexible parametric terrain model, orovides the required 
capabilities to realize a hierarchial representation. The 
level of resolution is orescribed by the requirements. 

The first study application of STAR was in support of 
the 105/120mm ammunition stowed load requirements for the 
XMel tank. Initial oroduction runs for the Study were 
conducted COR a blue battalion versus a red reaiment in 
December 1978. This version of STAR reoresented all 
appropriate ground direct fire units, tworsided artillery, 
minefields and smoke. Upon completion of the Phase lf! 
battalion-level production runs Con a 10 x 10 km 
battlefield), Phase II was initiated. The result of Phase II 
was a brigade=level model versus a red division on a 
battlefield approximately 50 x S50 km. The Phase II model 
will be capable of simulating a multi-echelon red regimental 
attack on multiole avenues of approach in both the Coverina 


Force Area (CFA) and the Main Battle Area (MBA). Extented 
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dynamic play of ammunition and POL resupply, as well as a 
significant enhancement of the tactical representation of 
battalion engagements, will result from the Phase II moael. 
In addition, artillery units will be directly represented on 
the battlefield, allowing for specific play o f 
counterbattery and counter airw-defense fires. Finally, a 
dynamic air-torwair defense model js being developed. for 
Phase II model representing twor-sided airw~tortair enqacements 
for both fixed and rotary wing aircraft. All appropriate red 
and blue air defense systems will be olayed in the model. 
The SIMSCRIPT language was selected for STAR because the 
language was designed for discrete event simulations. The 
many embedded features of the language qive the proqrammer 
wide latitude in the construction of event flow. “The 
lanquage is Englishwlike with regard to the construction of 
commands. The heart of the embedded simulation facilities 
1 the timer, which is used with certain St ruetuira) 
characteristics: entities, attributes, sets and events. 
These facilities greatly simplify the process of writing a 
simulation program and debugging the code. This is further 
enhanced by a compiler which provides error messages”) and 
trace=back routines similar to WATFOR and WATFIV inf’ FORTRAN. 
me structure of STAR begins with the concept of = an 
entity. An entity is simoly a representation or model of an 
item. In STAR the basic entity 18 a weapon system 
representing tanks, TOWS, artillery pieces, etc. Any of 


these entities may be brought into existance by ae simple 
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ohrase, which includes the name of the entity. For example, 
the phrase CREATE A TANK reserves a place in memory for the 
entity and its attributes which the proqrammer has chosen to 
call TANK. Associated with the word TANK is a= pointer 
variable which ooints to the location in memory where TANK 
is stored. os is desirable to associate certain 
mmaracteriStics with entities after they have been created. 
These characteristics are referred to as attributes and are 
affixed to an entity by the internal bookkeeping procedures 
of SIMSCRIPT (the system) or are olaced on the entity by the 
programmer. Attributes must be changed by the programmer as 
necessary to reflect changes in characteristics. Moreover, 
the system will change system-defined attributes as 
necessary. The concept of sets in SIMSCRIPT is very useful 
when it 1S necessary to grouo entities based on certain 
characteristics or in the construction of aueues. In STAR 
sets have been used primarily to portray membership in 
organizations. fhe set structure mirrors organizational 
Structure and enhances the orogrammer's ability to model 
unit tactics from amicro to macro tlevel. An entity may 
belong to any number of sets and the entity acauires a 
membership attribute which facilitates identification of an 
entity's unit. 

An extremely flexible method of filing allows entities 
to be ordered ina set by ranking of certain attributes or 
by a simple firstrine=firsteout basis. STAR uses the latter 


ayemem for most aprnlications. The set logic of SIMSCRIPT 
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allows this to be easily expanded to higher level 
organizations. 

Each entity in STAR is modeled to reflect ae flow of 
activities over time. In particular, each entity initiates 
or undergoes search, detection, target selection, firing or 
impact. These five events are scheduled dynamically based on 
the current tactical situation or an appropriate probability 
distribution. When an event is scheduled for an entity, the 
SIMSCRIPT timer makes a record of the time that the event is 
to occur (in terms of overall simulation time) and the 
entity for which the event has been scheduled. Other 
Characteristics of the event may be recorded in a manner 
Similar to the assignment of attributes. At the appropriate 
simulation time, the event 1s executed unless cancelled by 
some logic provided by the programmer. fhis event, when 
created, would be filed in an event set which containea, 
among other things, the time that the event is to take 
place, the entities involved in the event and the event 
location with respect to other scheduled events. When xX 
seconds had elaosed from the current simulated time, the 
event would take place and the consequences of the logic 
written in the event routine would be executed. Event 
routines may 1nNn turn generate other events. FIRE, for 
example, causes the scheduling of an [IMPACT event. IMPACT 
leads to the scheduling of other DETECT and TARGET.SELECT 
events. 


Event routines are supocorted by a number of 
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computational subroutines in STAR. Subroutines are written 
in both SIMSCRIPT and FORTRAN which has given the simulation 
a great deal of flexibility. The difficult line-of-sight 
calculations, for example, are accomplished in FORTRAN 
because the terrain model was oriqinally written in FORTRAN. 
It was this capability to call FORTRAN subroutines that made 
SIMSCRIPT an even more appealing language. Existing FORTRAN 
routines could be used with only minor modifications. Other 
routines more closely tied to the entity structure of 
SIMSCRIPT were written in that language. The routine that 
updates the list of detected targets for each TANK is 
written in SIMSCRIPT to take advantage of the dynamic 
dimensioning capabilities of the Jlanquage and the pointer 
variable link listing techniques available. For large target 
arrays, these language features are extremely efficient in 


reducing memory requirements. 


Meee ROPOSED ENHANCEMENTS 

The STAR combat model currently under development at the 
Naval Postgraduate School operates in batch mode on the IBM 
560-67 computer in the W.R. Church Computer Center. I[t is 
difficult to build a simulation model in a batch processing 
environment. Batch processing consumes much of the time in 
developing the simulation. Interactive simulation is more 
economical as well as more effective in problem analysis. 
One of the primary goals of this oroject is to expand the 


model to operate in an interactive mode with aqraphical 
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support. Figure e.1l depicts the goals of this project. The 
modeler's ability to debug a simulation is greatly enhanced 
by the interactive capabilities of a lanquage. Since the 
simulation user 18S constantly engaged in uograding his 
simulation, interactive capabilities are an important 


feature of any support system (Mills and Phil 1977). 
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The ability to actively particioate in this war game in 
an interactive mode would contribute tO Eboth the 
productivity and the flexibility of the model. Ins an 
interactive environment, the player or modeler would be able 
to input decisions that would approximate those made by the 
commander on the obdattlefield. JThrough this man-computer 
symbiosis, the ability of the model to more accurately 
reflect the actual outcome of a battle would be attained. 
The actual flow of the battle could be altered to reflect 
realism rather than rigid programming which could lead to 
unforseen, unrealistic circumstances. 

A orimary concern in the desian of an interactive 
Simulation system should be ease of user particioation in 
the simulation during execution. To facilitate this ease of 
US@r an appropriate interrupt facility is necessary to allow 
for suspension of the orogram at a given point in- the 
Seoagran logic and for the transfer of control to the user. 
The interrupt handler should be flexihle enough to process 
any appropriate request at any time and return control to 
the point of the interruption upon completion of the 
handling of the interrupt. This interrupt facility would not 
only allow inout to the model and output from the model but 
also suspend the simulation to allow detailed examination, 
decision making and synchronization between simulation time 
and walleclock time. 

The model should operate in real-time if poossibdle. The 


term real-time, in the modeler's sense of the term, 1S not 
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entirely critical. In modeling terminology. realetime is In 
the sense of walle=clock time. One minute of clock time 
constitutes one minute of simulation. [f simulation of a 
thirty*minute battle runs in thirty minutes of wall clock 
time, the simulation is said to run in real time. Real-time 
in the computer science vernacular is of utmost importance. 
A computer system is said to be running in real-time if 
there 6 a comouter Orogram and some other orocess running 
"Inesteo”" in such a way that the associated process is not 
caused to run slower by the comouter program. This could be 
exemplified by the simulation program and the  graohics 
disolay orocess. If the simulation program sufficiently 
slows the interactive graphical Inout process that the 
inputs are received after they were needed for use 1n the 
Simulations then the computer system 1S not PruNNnINa itn 
real-time. The interactive canoability of tne model will be 
meeess if the inouts are not entered in sufficient time to 
effect the outcome of the battle. It is this real-time that 
the system must achieve. 

Facilities are needed to save the state of the model at 
any time by executing a single command. Conversely, a 
command should be available to restore the simulation to a 
previously saved state and execution resumed from there. 
Such a caoability provides the ability to save intermediate 
States of the simulation run for the purpose of returning to 
the previous points in simulation time. This technique 1s 


valuable in cases where an unexpected behavior enters the 
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simulation or an important behavior was bypassed before its 
presence was discovered (Sohnile 19/73]. 

Since the primary purpose of the game is to function as 
an analytic tools, any support system must be capable of 
recording all interactive decisions for use in duplication 
of runs with alternate modeling parameters. The flow of the 
battle should also be recorded in order to allow in depth 
analysis at the conclusion of the simulation run if desired. 

There has been little imaginative use of comouter 
Graphics as an input/output tool for simulations. Some use 
of simple plotting has been used but the power o f 
interactive graphics is relatively Untouched. Interfaces to 
graohics languages will permit the modeler to provide more 
meaningful displays for the simulation user. Ineut dy way 
of graphics has been grossly underestimated. Special 
Purpose graphics input is a natural means of getting inout 
with today's interactive graphics devices. 

The most fundamental capability o f the prooosed 
graphical] supoort package 1S displaving maos of the 
battlefield. The standard map is a 10 XK 10km contour map. 
This map would be plotted by referencing one of 25 standard 
map sections. These 25 standard map sections would cover the 
50 X SOkm battle area. By selecting one of the numbers from 
1-25, the approoriate contour map would be drawn using the 
default contour interval of 100 meters. An alternate mode 
for plotting maos would be orovided to allow the plotting of 


larger areas. Laraqer maps are required to monitor such 
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missions as counter=battery fire or long range surveillance. 
These larger plots would be called by referencing the lower 
left corner and the upper right corner utilizing four digit 
grid coordinates. Since the area to de plotted would be 
larger (Cor smaller if so desired) a contour interval must be 
supolied. Scaling wil] be poperformed as ae function of 
maximum and minimum grid coordinates specified. 

The contour maps orovided are the background for several 
types of overlays. These overlays may be selected singly or 
in any combination. The plotting of excessive numbers) of 
overlays may lead to cluttering of the display screen and 
should be avoided. One such overlay is 1n supoort of the 
dynamic smoke module included in the simulation. The smoke 
overlay will show the location of smoke or other oboscurina 
elements such as fog or rain. DOensity of the smoke is 
indicated by the intensity of the disolayed smoke. As the 
smoke dissipates the intensity decreases. The effect of wind 
on the smoke is shown by movement of the smoke display 
across the screen. Results of oatrols and reconnaisance 
flights will be overlayed on the basic contour map. Tarscets 
detected by both ground and aerial observers are displayed 
while under observation. The results of active ground 
detection will be updated as required by movement. of 
elements. The results of aerial reconnaisance are static In 
mature after the completion of the flight. Other overlays 
include the disolay of road networks, townsSs oostacless, both 


Natural and man mader animation of firing events, receipt of 
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enemy fire, nuclear planning aids and indirect fire. 

Dynamic route and position selection will be supported 
from the graphics terminal. By utilizing a light pen, data 
tabletr cursory track baller joy stick, thumb wheels or some 
other type inout device, the player should be able to 
interactively input changes or supplimental information into 
the mode} durina execution. The graphical supoort package 
also provides for the monitoring of unit movement through 
the use of periodic updating of the current unit position. 
During execution the modeler can select the level of the 
unit to be plotted. If the modeler selects a unit level 
other than individual element, the elotting of the unit 18s 
performed using the standard military symbol for the unit. 

Dynamic movement on the battlefield aives additional 
realism to the simulation and often discloses information 
that words cannot convey. Unit movement 1S represented as it 
occurs. The (actual fiinNaoOt weapons to include round 
fliaht and impact enhance the picture. Any combat introduced 
visual effects such as smoke from exploding rounds 1s 
Gepicted along with its dissioation and drift. One of the 
largest benefits of displaying unit movement is having a 
tool to debug the dynamic route selection module that will 
be develooed for STAR. Uniess the modeler has the capability 
to monitor the route taken by an elements, he can never 0obe 
certain of the performance of dynamic route selection or 
where that element is located. 


Another analytic tool to be furnished the modeler 1s the 


ao 





ability to draw linesofesight (LOS) fans. These LOS fans are 
used to aid in selection of positions for weapons systems, 
radars and other LOS dependent systems. Analytically, these 
LOS fans serve to verify LOS calculations for firing events. 
The LOS fan will be represented by shading on the contour 
map, the heavier the shading the greater the visability. A 
second type of LOS fan will be offered, this being a 


compliment display that shades the area that cannot be seen. 


The Support system will incorporate an inquiry 
capability. Whenever a simulation creates significant 
output, the statistics collection capabilities of the 


simulation lanquage may not provide the modeler with the 
information needed. Statistics collection by a simulation 
language is often too general and if more detail) 1s 
required, a dump of the state changes of the model must be 
analyzed. This inquiry capability supports post execution 
analytic analysis by enabling specific information to be 
retrieved and thus avoid searching volumes of data to obtain 
a Single data item. This feature of the war came allows the 
various players from staff sections to inquire and receive 
information concerning any data the model maintains that is 
normally available to that staff member. For examole the 
G-1/S-1 needs information concerning command strength, 
losseSy, individual and unit reolacements, friendly and enemy 
Prisoners of war (POW), civilian personnel, safety, 
personnel serviceS, graves registration, casulty reporting, 


awards and decorations, medical supply and maintenance, 
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straggler disposition and headquarters movement, security, 
operations, rear command post location and visitors. The 
G=-2/S-e is concerned with recommending essential elements of 
information (EEI), requests for target acquisitions, 
surveillance,s, reconnaisancer interrogation of enemy POWs, 
debpriefingr, captured enemy documents, signal intelligence, 
‘intelligence interpretation, weather, predicting NBC 
fallout, situation maos, counterintelligence, recommendina 
proposed areas of operations to the G-3/S-3, intelligence 
trainings aagressor forces if employed, civilian=military 
operations and camouflage. fhe 673/573 is tasked with 
insuring the number and types of units assiqned to support 
and accomplish the mission, attachment and detachment of 
uUNItS*s, OFGAaNIZING and equipina units, trainings, preparing 
the operational estimate, integration of fire and maneuver, 
basic and special loads for weapon systems, oriorities for 
allocating critical resources, coordination and use of 
airspace, designation of bivouacing areas, recommending 
general location of the command post, electronic warfare 
activitieS*r communications” and maintaining 5 current 
estimate of the situation. The Ge4/S"4 is concerned with 
matters of supplyr monitoring the distribution of supplies, 
Supervising the distribution of critical combat weapons and 
MUNItIONSs, recommending prescribed loads, managing special) 
wWwEQD0NS, procurement and storage of special we aAPONns, 
collection and disposal of excess equipment, maintenance, 


repair partS, evacuation or retrograde of unservicable 


on 


equipment, transportation, refueling, construction, property 
control, food services, use of POWS and civilians and 
decontamination operations. This data is available in a 


tabular form similar to figure e.cd. 


TABULAR DISPLAYS 


"INGRES FLAVOR" 
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FIGURE e.e 
The graphics package will include the capability to 


represent terrain in three=dimensional form. This facility 
enables the modeler to verify that the shape of the terrain 
used 1n the model is in reality a true representation of the 
actual terrain. Three-dimensional terrain plotting also 
Serves to verify LOS calculations and aids in selection of 
routes and positions. Through the use of three dimensional 
terrain, aircraft flight simulation is ovossible. Tne viewina 
screen is capable of displaying terrain as seen from. an 


aircraft. The display includes the terrain, vegetation and 
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all elements located on the terrain being traversed. 
Additionally this ° three=sdimensioned terrain feature can be 
expanded to provide 360 degree scans from any point selected 
by the user. 

The use of color in graphical displays was determined to 
be of extreme imoortance. The representation of red and blue 
forces is an obvious advantage. The ability to use color to 
represent vegetation lends realism to the display. The 
number of items to be represented 1s so large that without 
color 16 will bem Giftficultye 1f mot Imoossibler to 
distinguish features displayed. 

A report writer 1s of practical imoortance to the 
analyst. This reoort writer will be highly formatted to 
provide statistics required by the analyst. The user will be 
able to swecify the statistics to be displayed and the table 
will be generated automatically. Additional] hard copy 
support will .be available in the form of a covy gevice 
attached to the terminal that may be used to copy the 
current tmage on the display device. = 

Any aqraphical supoort system devised would not be 
complete without oroviding assistance to the user durina 
execution. Instructions for use must be available, on call, 
at any timer, with various levels of detail for various 
levels of experience in olaying the game. This type of 
interactive counseling will be orovided in the form of a 
helo function. - This help function will be orovided for two 


levels of expertise, the novice and the experienced. The 
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novice user needs information concerning functions 
available, their formats and their commands. The expert, on 
the other hands requires only a reference to the commands 
available since he is familiar with their formats. 

Certain tutorials and guides must be supplied to the 
user. Directions for position selection using the line of 
sight fans must be readily available for use during setup of 
the simulation. A military symool library should be 
included with the descriptions of the available symbols = and 
the method of placement of the symbol of the overlay. This 
description includes details of how the computer decides 
where the automatically generated symbol is placed. Any 
Graphical Support provided for this system must provide’ for 
an interactive means with which the user can generate the 
Parametric terrain and verify it against the actual terrain 
or 2 map. This terrain voackage must provide not only 
assistance in design of the terrain, but also the capability 
to record the parameters selected for later use in the 
simulation. It 1s highly desirable that the user have the 
means to obtain a hard copy of this terrain generation for 


this verification process. 


E. TYPES OF GRAPHICAL DISPLAYS 

The graphical support package will consist of three 
Separate types of apolications packages. The first tyoe of 
support is provided in the form of monitors. These monitors 


are the devices that provide the selective terrain plots. 
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The terrain plots are selected by the user and displayed 
until the user elects to either terminate the display or 
request another sector. The display monitor reflects 
current unit movement located within the terrain sector. 
The user has limited control over functions of these 
monitors. These monitors have the basic function of 
displaying the contour maps. The user will be able to select 
from a standard set of 10 X 10km contour mapsr or he may 
specify a sector using grid coordinates and the desired 
contour interval. The user may also specify the unit or 
element to be displayed. These monitors have ae selective 
zoom feature to allow the user to focus on a given area in 
greater detail. 

A second type of display incorporates the inquiry mode 
of the support package. These displays will be alpha- 
numeric terminals. These terminals enable the various staff 
players to inquire about personnelsr logistical and other 
routine affairs of a unit. Levels of itinauiry are controlled 
by the user. The terminal initiates a hierarchical search 
with the hiaqhest level unit available, giving the ontion of 
making the inquiry at this level of resolution or displayina 
subordinate units at a level one unit lower. If the user 
elects to make his inquiry, then action is initiated to 
determine the type inquiry from a menu of possible choices. 
The information is then displayed and execution continues. 
Should the user elect to traverse through the hierarchy in a 


downward direction, the monitor will display the Subordinate 
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units and ask the user to indicate the unit in which he 1s 
interested. This 1S continued until the user reaches the 
level he desires and the inquiry is initiated. 

A third type of display will orovide the function of the 
master graphics console. This console is fully interactive 
and accomplishes all dynamic changes and selections in the 
program. This terminal is anticipated to be larger with 
greater resolution. The Seana y for drawing in three 
dimensions is realized at this terminal. All graphical 
requests are originated at this terminal with the possible 
exception of the itnauiry functions. Inquiries may also be 
initiated at the alohasnumeric terminals. For ease in 
selection of the function to be performed, a menu selection 
technique is used. The user selects, by means of a light=cen 
or some curser positioning device, the desired function to 
be performed. This initial selection leads to the 
fullfililment of the user's request or the display of another 
menu. In addition to providing the executive routine which 
manages the execution of the simulation, the monitor 
provides the ability for the user to interact with the 
Simulation program directly from the terminal. This allows 
the user to not only observe, verify and record data, but 
also interruot the simulation to change parameter values or 
modify the model structure. Fiqure 2.3 depicts tynes of 


aisplays. 
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GRAPHICS DEVICES 


oe @ eo 


MONITORS INTERACTIVE TABULAR 
CONSOLE DESPEAYS 


"INGRESS FLAVOR" 


FIGURE 2.3 


Bi 





Pet weanNGee TAL SOLUTIONS 


The problem at hand is to imolement graphical support 
and inaquiry capability to an existing war game without 
serious degradation of performance. This problem is 
generated by the merging of several capabilities. These 
Capabilities include maintainina a real time environment, 
sharing of common data items without data redundancy, 
process synchronizationry accurate and timely displays and 
interactive participation by both the user and orograms. 
The puzzle is to fit these areas into a comolete picture. 
This puzzle is the very essence of this thesis. The basic 
problem has been simplified by one assumption. The type of 
computer utilized is irrelevent providing it is capable of 
performing to the specified standards. The question of 
mini, maxi or micro implementation revolves around the state 
of the art at implementation time and the purpose of the 
computing system itself. If this simulation system 1s to 
become highly portable, then the preferred choice may be a 
microcomputer due to its low cost and pvortability. If this 
simulation system is to run "stand=alone” on aie dedicated 
System, then it may be appropriate to develoo the system on 
a minicomouter. If this simulation system is to share time 
with other programs in a multiprogramming environments, then 
the approoriate choice may be a large mainframe capable of 


both multiproaqramming and multiorocessing. This thesis 
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leaves machine choice to the individual implementer. 
Solutions to the puzzle fall into four general classes 
with various degrees of difficulty and overformance 
Standards. These choices include a database management 
System, a tailored operating system, a distributed system 
and aqraphic subroutines embedded within the simulation 
meeelté. Grief descriptions of the characteristics of these 
four aporoaches are discussed in the next four sections. 
Section — evaluates each aporoach's ability to implement the 
simulation system. The oreferred solution 1S chosen in 


Section F. 


A. DATABASE MANAGEMENT SYSTEM 

One approach to the oroblem of supolying graphical 
support to the STAR model is through the use of a database 
management system. A database management System iS a 
collection of software procedures, designed to facilitate 


access to a data base. This data base is sharea by diverse 


users. In this approach the main simulation program, 
written im SIMSCRIPT, would act as a high-level lanquage 
applications program. The user would interface with the 
applications Program through the use of any Standard 
alphanumeric terminal. The graphics routines would act as 
Other high-level] language applications programs. Since a 


database management system has the property of being able to 
present the same data to various users in aciffering formats, 


the applications programmers would have their own external 
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models of the data available to them [Curtice 1976). This 
differing view would allow the graphics programs to be 
written in some language other than SIMSCRIPT since at this 
time there iS no provision for graphical support in 
SEMSCRIPT. 

The actual data that is being manipulated by the 
applications program is stored ina common area within the 
computer system. The function of the database management 
system is to allow the sharing of the data and create data 
independence to allow for different views of the data. Het 
is the responsibility of the database administrator to 
develop and maintain the schemas allowing this mapping to 
occur (Martin 1976]. 

Database management systems must interface with the 
operating system in order to accomplish the actual manning 
of data into memory. The operating system and the <aatabase 
management system must coexist, but this does not 
necessarily timit the usage of a database management system. 
Operating systems are available under which any  aiven 
Gatabase management system may operate. There is an 
important relationshio that must be discussed. Database 
management systems and operating systems provide the user 
with a variety of common functions. The database management 
System desiaqn must take into account the services provided 
Dy the ooerating system in order to minimize costly 
duplication. Some of the most common services provided by 


operating systems include process management, filesystem 
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support, inout and output support and usage measurement 
(Wiederhold 1977). Some operating systems also provide 
facilities for sharing of data seaqments (Organix« 1972). 

The use of a database management system has several 
advantages. The database management system supports multiole 
users of the system at any given time. Data redundancy is 
reduced if not eliminated. Aoplications programs are data 
independent. The database management system provides 
internal safeguards for data integrity [Date 1977]. Post- 
execution analysis is also facilitated. The ability of a 
user to conduct inquiries 1S Simplified by the adoption of a 
highly tailored data manioulation lanquage. 

A database management system offers a broad range of 
facilities for 5p DORR viewing and Naehiotiat ina 
information. The creation of data tables by the user 
reQuires only aminimum knowledae of the system. Often new 
tadles can be constructed automatically from existing tables 
on the basis of some format property of the oriainal table 
(Fram et.al. 1977). 

Typically, data manioulation languages are written in 
English-like commands. With minimal training, a novice user 
Can do useful work on the database management system using 
the data manipulation language. Many of the more common 
commands may be invoked in a dialog form in which the system 
Prompts the user for additional data or instructions. 

One of the largest disadvantages is the addition of more 


overhead and hence additional execution time. Part of this 
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probem may be overcome by the design of a-compiled database 
management system instead of an interpreted one [Wiederhold 
1977). In a typical database management svstem, a single 
user command may result in the performance of several 
ohysical inout or output operations. Each inout or output 
operation must be initiated by the central processor unit. 
In a multiprocessing environment, this requires the seizing 
and releasing of the central processor unit several times to 
carry out a user command, therefore a siqnificant overhead 
due to task switching may be accrued. The order of 
increased complexity introduced to the system by the 
database management System concept must be considered. 
Database management systems are considered by many to be as 
complex as some operating systems and hence introduce an 
additional complexity factor over and beyond the operating 
System and the basic application programs. Figures 3.173.2 


diagrams the roll of a Database Management System. 
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B. OPERATING SYSTEM 
Modern computer hardware 1S very powerful and may be 
used for a variety of tasks. The hardware machine 15 


difficult and awkward to use. In order to simplify usage of 
the bare computer, operating systems have been developed to 
Provide a more hospitable interface with users. Operating 
Systems have become so _ essential to efficient comouter 


operation that many peoole view them as inseparable from the 
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hardware (Madnick and Donovan 1974). 

An operating system is a collection of software modules 
within the computer system that control the operation of the 
comouter. These modules simplify the use of the system, 
attempt to optimize performance and resolve conflicts within 
the system. The modules manage the orocessors, main 
storage, secondary storage, inout/output devices and files. 
The operating system performs the ‘see of scheduling the use 
of the computer. Sophisticated operating systems increase 
the efficiency and subsequently decrease the cost of using a 
comouter. 

Operating systems vary in complexity from simole monitor 
Systems on microcomouters to soohisticated larae scale 
systems canoable of multiorogramming and multiprocessina 
while providing protection and interrupt hardware. 
Regardless of the complexity of the system, aalet operating 
SyStems orovide binding for processors and memories. The 
operating eee fi binds data to physical memory locations and 
outout files to output devices. A process 1S bound to a 
processor. [The ability to perform binding is fundamental! to 
all operating systems. 

Operating systems are somewhat distinct in their ability 
to provide protection mechanisms {Graham and Denning 1972). 
The first level of osrotection provided by operating systems 
1S common to al! reliable systems. This iS the protection 


of the operating system itself from destruction by tampering 


Gue to the executing program. This tampering may be 
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accidental due to the miscalculation of a subscript or some 
similar mistake, or it may be an intentional effort to 
SabDatoge the system. Whatever the source of the tampering, 
the operatina system must protect itself. A significant 
difference in operating systems is the ability to protect 
classified data within the computer system. Some computer 
Systems are secure only in the dédicated mode where only 
classified material 1s allowed in the computer and the 
security perimeter is external to the machine. A more 
comelicated but more useful tyne of security 1S the 


multilevel mode. In the multilevel mode the system may have 


various users with varying levels Of security 
classification, all comoeting for system resources 
simultaneously (Whitmore et.al. 1973). The security 


perimeter 1s internal to the comouter and provided by a 
mechanism of the operating system. Access permission 1s 
determined by the operating system. This security mechanism 
may implement a descretionary or nondescretionary ee 
Some operating systems are capable of multiprogramminga. 
In a multiprogramming environments, several user programs are 
alloweq to compete for system resources simultaneously 
[Dennis 1965). It is the function of the operating system 
to decide which job will be run at any given time, It may 
be possible for the user to define the priority of the job 
to the operating system. [f this is the case the operating 
System does not have the problem of enforcing a 


descretionary priority policy. Determination o f the 
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oriority may be left to the operating system. Operating 
systems use various criteria for establishing priority. 
Methods include estimated length of execution, estimated 
storage requirements, estimated execution time and estimated 
output lines. An operating system may also use a 
combination of these two techniques. I[t is left up to the 
operating system to limit the number of orograms the svstem 
will accept. 

Some operating systems allow multiprocessing (Smith 
1977). In a multiprocessing environment the computer system 
has multiple erocessors, each capable oO f independent 
operation. cx is the responsibdility of the central 
processor unit (CPU) to coordinate or synchronize the 
functioning of the processors. In a system such as this it 
will be possible for one oprocessor to be performing 
calculations while another processor is controlling output 
to the line orinter. 

The operating system not only provides memory management 
in the form of binding but also 18 capable of creating 
virtual memory. Virtual memory allows the address space of 
the program being executed to be either greater than or less 
the the physical memory of the machine. Utilizing this 
virtual memory, the user need not be limited by the physical 
Size of the main memory (Denning 1970). 

Another feature of operating systems is their ability to 
handle interrupts. Through the use of an interrupt handier, 


the operating system may acceot an interruot, orocess it 
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Becording to the instructions tin the interrupt handler and 
return execution to-the program in orogress at the point. of 
the interrupt. Operating systems have system defined 
interrupt handlers but many have provisions for the user to 


define his own interrupt handlers. 


Be OLSOIRIBUTED SYSTEM é 

A distributed system is a computer system comoosed of 
multiple central processors that cooperate in proolem 
solving. These CPU'S may be spread cver many miles. or 
located in the same room. In order for the distributed 
system to functions, coordination between the processors 18S 
accomplished by a distributed operating system. 

The problem of extending the execution time of the model 
might be alleviated by the concept of a distributed 
computing system composed of one computer to process’ the 
simulation portion and maintain a master data base and a 
smaller computer oroviding the graohics and jnauiry 
capabilities. A distributed system has the chacteristic 
that the functions are distributed or spread over multiple 
CPU's each designated to handle a particular function. This 
approach becomes advantageous by using a second processor to 
reduce the work load of the main CPU. Consider the case of 
a fronteend processor connected to a main processor as 


indicated by fiqure 3.3. 
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The fronteend processor controls the interface with the 
user. Graphical displays and user command interpretation 
including editing are performed on the frontend orocessor. 
This allows the power of the main processor to be devoted to 
the comoutation bound simulation functions. In this case 
the main orocessor would have to pass the required display 
data to the graphics processor as needed. Assuming that 
this would take a smal] amount of time unger CPU to CPU 
communication with a communication line of high transfer 


rate equal Eo the slower rate of the two processors,e the 
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main processor could continue to simulate while Ene Qracnics 
processor aenerates the display list and causes the display 
to occur. This would have the effect of halting the 
simulation for only a minimum time frame and thereby not 
significantly degrade the system. Should it be desirable to 
stop the simulation for some update of information from the 
graohics processor, an interrupt could be generated by the 
graphics processor and sent to the main processor which 
would then halt the simulation to receive the update. The 
problem of maintaining data integrity emerges from the 
aforementioned situation. There 1S no way to determine if 
the data to be changed exists at the time of uodate or if 
the data displayed 1s current. This problem wil! have to be 
resolved by generating an undate request, displaying the 
current status of the battle area and then updating the 
data. This must be handled through some automated means so 
that the user is not confronted with the oroblem, he has 
enough to be concerned with without the system comolicating 
the situation for him. 

The distributed system functions as follows. First there 
meet be established priorities that each CPU follows. For 
Instancer on the simulation CPU, communication between CPU's 
has a higher priority than the simulation and can be 
represented by the following oseudo code,"while (not 
communicating) do simulation". This action will give 


priority to CPUSCPU communication, allowing the user's 


inquiries to be answered more raoialy. The graphics CPU 
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continuously tests the terminals for the indicator that the 
user desires to perform some function. This can be also 
accomp!]ished through an interrupt mechanism. Upon 
identification of the user's desired functions an argument 
list is constructed in conjunction with additional user 
supplied data, if requireds, and an interrupt is generated to 
the simulation CPU indicating that the graphics CPU desires 
to communicate. Upon receipt slp the argument list the 
simulation CPU stops the simulation, stores the machine 
state and executes a "case" structure similiar to: 
Switem fumetion=10)'> 

at, terrain information; 

case(i)J: inquiry; 

case(u): update; 


® 


} 
passing back to the graphics CPU any resultina information. 
The graphics CPU now processes the information received from 


the host CPU and continues the humc ct 1om Or aime lly 


identified by the user, such as Producing a display. 


D. EMBEDDED GRAPHICS 

The simolest and perhaps the most direct implementation 
of the desired capabilities is the execution of the graphic 
Capability from a direct subroutine call from the SIMSCRIPT 
Simulation program. Figure 3.4 depicts the embedded graohics 


approach. 
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SIMULATION SIMULATION GRAPHICS 








ROUTINE 1! ROUTINE e ROUTINES 


FIGURE 3.4 


There are several advantages to this approach. The graohics 
package can be developed separately from the simulation 
models keeping in mind that necessary parameters required by 
the display must be oassed from the simulation program to 
the graphics subroutine. A simple driver could minic. the 
Mmemetions of the call torptnmeagraphies routine curing thre 
development of the graphics package. In the same way, 
should the graphics subroutine provide the interface with 
the user for the interactive oortions of the model, certain 
Parameters would have to be returned to the simulation 
program. These oarameters must define the type of funetion 
that the user desires to oerform along with any function 
parameters reauired. The values of the parameters could be 


established through interoretation of light pen input from 
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the user. This interpretation could take the form of a CASE 
or nested IF type structure where parameter values would be 
established from an interpretation or series o f 
interoretations of the light pen inout. Once the parameter 
list is formed the graphics subroutine is called. 

There are disadvantages to this concept. Due to the 
mature of subroutine calls, the action of the simulation 
program is at a standstill] until] he execution of the cal! 
is comoleted. This will increase the execution time of the 
simulation program and thereby increase the walleclock time 
required to simulate any given battle. This problem ceases 
to retain great importance if it is desirable that the 
simulation be halted to allow any update information to be 
passed to the simulation process and thuS maintain data 
integrity. 

Because data inteaqrity is a requirement of the system, 
the graphical displays must be capable of depicting the 
exact state ee Simulation upon the display device. ike 
change the route of march of a particular unit or element 
that item must be located in the depicted position at the 
time of the update or the exact position must be known to 


the user. 


E. EVALUATION OF ALTERNATIVES 
1. Common Considerations 
There are several items that are common to all 


approaches. Included mn these items are the use of color 
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disolays, hard copy devices and the treatment of static data 
such as contour maps. Hard copy devices are required to 
record selective displays upon command of the user. Contour 
maps are thought of as any required data to enable a rapid 
draw of the desired area of terrain. Once the parametric 
terrain data 1S constructeds, prior to the simulation 
execution and during some system initialization procedures, 
there is no need for the Situieusion Process to have access 
Semrt since the simulation routines compute any required 
terrain data dynamically during execution. There is only the 
need to have this data available to the graphics display 
routines. The impact of a hard copy device upon the 
solution is seen as device dependent and therefore not. of 
concern in the selection process. In the same manner the 
method of drawing contour maps is device dependent and the 
use of color is independent of implementation. These two 
factors are also omitted from the evaluation orocess. nas 
evaluation ee se Sfeeuten aot y or iiinability of the 
alternative to Support the simulation, evaluating failures 
on the lowest possible level. 
ec. Database Management System 

In the database management system approach, the 
Simulation program assumes the role of a high-level lanquage 
applications program. All grapohical routines except the 
inquiry program are also hiah-level anoplications orograms. 
The inquiry program is an aoplications program written in a 


tailored data manipulation language. 
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A database management system 1s designed to allow the 
sharing of data and eliminate data duplication. Through the 
design of appropriate schemas, the database designer 1s able 
to present each apolications programmer with an independent 
view of the data and allow the orogrammer to access any data 
within the data base. This aoproach presents a problem with 
multipole users attemoting to write data simultaneously. 
This problem can be minimized anriouar careful design and 


judiciously granting write access to shared data. Shou 


two users desire to write data to the same file, the last 


copy written will prevail. 
The recording o f dynamic events presents a 
significant Problem to the datadase management system 


approach. The ability of the system to accept and store 
Inout data from the uSer 1S routine to a database system. 
Anything that can de input and stored may also be recorded 


on secondary storage media. The significant problem arises 


“ 


when the machine state must be saved. Only the operatina 
system has the capability to monitor and modify all) the 
registers in the machine. For the database management 


System to save the machine state, close cooperation with the 
operating system 1s required. When it 1s desired to return 
to a decision ooint to resume execution with another 
Gecisiony, the database management system must relinauish 
contro] to the operating system while the operating system 
FeStores the values of the variables and the machine state. 


Fiexibility of play wil) require the database 
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management system to maintain some mechanism to generate the 
appropriate data structure for the level of play. The 
flexibility of olay 1S not an inSurmouNntable oroblem but the 
mechanism to achieve this goal may be quite complicated. 
The flexibility of display will be quite easily attained 
since disolay 1s deoendent only on the data stored once the 
Gata structure for storing the data has been created. The 
ability to store various force structures must also be 
attained by some dynamic means since the actual size of the 
Gata structure required will not be known until run time. 


The degree of interactive orogramming attained by the 


database management system will vary from routine to 
routine. The inquiry routines wil] have the full 
interactive Characteristics of any database management 
system. The programs written In highwlevel languages are 


limited by the degree of interaction provided by the 
corresponding languages. The database manaqement system has 
no means of Incorporating interruot driven orocessing. 
Interrupt driven processing requires action by the operatina 
SyStem and therefore a close relationshio between the 
database management system and the operating system. 

The database management system aporoach wil] 
adversely affect the real=time capability of the program. 
Overhead in a database management system is extensive. The 
Gesirable trait of data independence requires the additiona! 
cost of address translation. Various references to the same 


data element require the system to translate these 
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references into the same physical memory OC at vom. 
Additional overhead in execution time is reauired by the 
necessity to translate or compile input requests during 
execution. 

The report writer 1s facilitated by the database 
management system approach. fhe database design allows for 
the user to request information in a standard format and 
have it displayed for him on sreieesecke Any information 
stored may be displayed as well as any combination of data 
items that may be created using relational calculus or 
Standard boolean operators. 

3. Operating System 

Under the operating system concept, the simulation 
program pecomes one o f many in a multtorogramming 
environment. The graphics routines are orqanized Into 
programs with related functions. These araphics programs 
become additional programs that will compete with all other 
programs for ees resources. 

The problem of sharing files 1S not siaqnificant to an 
operating system that uses seamentation. <Any progran 


Givision that 1S important enough to be named may be created 


as a segment. In a system supoorting this seamentations any 


segment may be addressed by potentially any oprocessor. By 
Careful desianation of the ability to read and write to a 
given segment, it 18 possible to allow a seqment” that is 


responsible for a file to create the file and to allow a 


segment that must use that data for display oor other 
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purposes to access the data and use ite These segments that 
are sharing the data need not be in the same oproaram. The 
orograms need only be. active at the time of sharing of the 
data. One potential problem may arise if more than one 
segment is allowed to write to any one data segment. In 
this case the last segment to write will be the Segment that 
dictates the data value written.- By careful! design of the 
programs involved, this problem may be made insignificant. 

The ability to record dynamic events sucn as 
decisions by the user and simulation status present no 
significant problem for the ooverating system. At the time 
the user inputs his decisionr the operating system needs to 
write the input data into the aoorooriate area 1N memory tS 
affect the simulation. At this same time the operatina 
syStem will make a copy of the decision information along 
with the machine state and any pertinate variable values 
before the decision is made. This additional information 
may be written to some secondary storage medium for use at a 
later time. At a later time wnen it iS desired to return to 
2 given decision point and change or modify the previous 
decisions, the operating system has all the information 
needed to restore variable values and restore the machine 
State. Execution may then resume from the point of decision 
rather than requiring the entire simulation to be executed 
againe 

In the area of flexibility, the operatina system 


approach presents No problem. te 1S. the normal fume © wom 16 ft 
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some operating systems to allocate storage for oproodolem 
elements. At execution time the operating system wil] 
allocate storage as required by the simulation Program. 

The area of interactive orogramming 1s affected by 


the interactive capabilities of the programming l]anguaade. 


These built in capabilities are the base level for the 
simulation. Further interactive capabilities may be 
provided by the operating system. For a system to. be 


genuinely interactive, it 1S necessary for the system to be 
interrupt driven. In an interrupt driven system, the user 
generates an interruot and the operating system then 
transfers control] to the appropriate interrupt handler. The 
meeeructions in this interrupt handler dictate the response 
to the interrupt. Operating systems allow the user to write 
his Own interrupt handlers to either suoplement or repolace 
the system provided handiers. In the event the user elects 
mom tO provide his own handler, the operating system 
Provides default handlers. By anticipvpating the required 
types of interrupts and the appropriate responses, the user 
may effectively interrupt the execution, create a display or 
input datar, and return to the point of interruption and 
continue execution. 

The operating system aporoach may enhance the real 
time caoability of the simulation. A multiprocessina 
environment allows the operating System a0) perform 
comoutation on one process while simultaneously performing 


input/output, Paging or some other operation on another 
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process. This means the programs of the simulation may 
fully utilize the processors of the comouter system and the 
processors need not be idle while a single Program switches 
from one processor to another leaving the rest of the 
processors idle until the simulation needs its services. As 
@ worst caser the opverating system will add no more 
execution time to the proqram. fhe operating system is 
needed to provide user interface vd the bare machine’ and 
hence iS already present as overhead to any Program run on 
the machine. 


The post analysis report writer is stil} another 


program to exist in the multiorogramming environment. The 


operating system keeps the segments belonging to al | 
simulation programs on call unt) | the report writer 
completes its usage of the data. Siecle ee GeOoct (writer 


concludes execution, the system is allowed to free storage 
for other usaqae. 
a. Migicsibuted System 

The envisioned solution would have two central orocessors. 
The simulation functions will reside on the main processor 
gue to it's computation bound characteristics, while the 
graphics and inauiry functions will reside under the control 
of another possibly smaller porocessor. 

Since the main CPU is charged with the responsibdility 
of maintaining the master data base, there can be no sharina 
of data items between orocessors. The aqraphics processor 


must receive all data items that are dynamically changing. 
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It must also interpret all user commands and generate a CPU 
to CPU request for the data items necessary to fulfill the 
user's request. Any attempt to store these ever changing 
items is fruitless and will result in either duplicated 
files or excessive data transmission between the two CPUs. 
The request for data must be be generated on an interrupt 
basis to the main processor so .that the- excessive data 
transmission and data redundancy situations do not occur. 

Dynamic event recording must be accomplished on odoth 
processors to enable system to be restarted at any specified 
state. The graohics processor wil] be required to store 
user commands and decisionsrs, machine state and perhaps 
disolay generation data. The main CPU will be tasked with 
Saving its machine state and all variable values for the 
simulation restart. 

Fiexibility of the system now soreads over the two 
processors. Not only must the imolementer be concerned with 
the mechanism for level of play, level of display and size 
of forces represented but also the corresoondina volume of 
data transmission between the two orocessors. ThiS 1S-— an 
added concern in the distributed aporoach. 

Since interactive play is desired, the graohics 
processor must interpret the user's commands 1n-— an 
interactive role and also generate an appropriate interrupt 
to the main ocrocessor for each type of request. This will 
require a user written interrupt handier on the main 


processor to decipher the interrupt and process it. The 


61 





interrupt handler will orobably not be -on the operating 
system level and thereby will cause additional delay orior 
to processing it. 

The idea of distributing the STAR system functions to 
two processors was concetved to solve the realetime 
requirement problem. Certainly the distributed system would 
meme closer to real-time than a Subroutine call system. The 
required CPU to CPU communication will generate some 
overhead that other approaches do not. The user must see the 
current situation status displays and his participation must 
be received in time to accurately effect the outcome of the 
battle. 

The problem of where to locate the report writer for 
posteexecution evaluation arises. It should be capable of 
providing the user with his requirements at the location 
generating the disolays. This means that the main processor 
must either continue to function only to pass data to the 
gQraphics processor for this purvose or create a file that 1s 
readable by the graphics processor during this phase. Once 
again additional overhead 1s required to accomplish both. In 
the first case additional execution time is required by the 
main to retrieve, process and transmit data to the graphics 
Processor. In the latter case additional time 1S required 
to create the readable file should the two processors expect 
different file characteristics. The overhead of generating 
the file remains in either case and under all concepts 


discussed, however such record and file attributes as 
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header, trailer, interw=record gapss blockina characteristics 
and character set will oresent a problem should two 
different hardware vendors be chosen for the two processors. 

Since unchanging data items, such as terrain and road 
networks, exist during the execution of any given 
simulation, they are stored on the graphics side of the 
System originally and do not require the passing of large 
data structures as that of terrain representation. This is 
possible due to the use of parameterized terrain generation 
capability of the simulation to produce terrain elevations 
at any agiven point on the battle field. 

5. Embedded Graphics 

In this aporoach the simulation oprogram is the center 
of control over all desired functions. The basic functions 
of graphical display, inquiry and update are fullfiled 
through calls to aporopriate subroutines. 

si MOCRIPT uses a basic technique of executing subroutine 
calls from the timing=routine. This technique selects the 
next event to transpire from the event list. FTnese events 
were previously scheduled by other subroutines in the 
Simulation (Cinternal) or received as input (fexternal). 

The sharing of information between the three basic 
functions (simulation, graphics and inquiry) presents no 
problem because the required common data can be stored in 
global variables or passed as arguments between the calling 
anc called subproarams. Oata integrity also oresents nO 


Particular problem since only one subprogram may be in 
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execution at any one time unless Some type of parallel 
processor is utilized. The same argument applies when one 
subprogram updates a variable value that another uses. 

The recording of dynamic events can be easily 
accomplished except for retention of the machine state. 
Since machine state 1S Important from the standpoint of 
restarting the process from a specified stater, an assembler 
leve] Subprogram 1S freauired a periodically save the 
necessary information on some secondary storage medium. 
Routines wil) also have to be developed to retain. the 
decisions reached and periodic simulation state, however 
these can be written in the basic simulation language’ since 
all required information is defined to the simulation 
program. 

Flexibility of the system for level of play, level On 
disolay and size of forces must be designed into the 
suborograms but may de realized through dynamic 
Maiization of key execution parameters. The structure 
to allow this must be incorporated into the subprograms” so 
that the maximum allowable force sizes can be allowed. 

Interactive play can be achieved through careful design 
and implementation. A suborogram to periodically test 
diseclay terminals for user participation is required. This 
Subprogram wil] interpret the user's desired functions and 
schedule the comeatadle event which is stored in the 
timing=routine event list in time sequence. These events 


may be scheduled NOW, IN 10 MINUTES, or AT 1430 HOURS, 
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however, NOW does not imply instantaneous execution of the 
function since other oreviously scheduled events for the 
Same time could exist with a higher statically defined 
priority. 

Maintaining a real-time environment 18S not hindered by 
this approach when considering effect on the outcome of the 
simulation, however this aporoach will extend the execution 
time required for the battle. Should the user desire to 
update the simulation data during the execution, the 
simulation process 18s halted by the resident operatina 
System until control is returned. The user need only 
schedule a display and an uedate NOW or at the same time 
with the display event having the next hiahest prioritv to 
the update event. Ouring execution the display will be 
produced, showing the current simulation status and then the 
update event will execute. 

The reportewriter enhancement presents some difficulties 
particularly during postesimulation evaluation. Since the 
execution of the simulation has been terminateds, a separate 
application orogram is required to process the saved data 
for the user. 

Although the subroutine call aporoach is the simplest to 
Implement, it does have the drawbacks indicated. This 
approach will have several beneficial sidereffects. The 
graphic disolay is scheduled along with ali other events and 
16 placed in the event list in the appropriate time 


sequence. A display event can be generated with the SCnHEDULE 
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A GRAPHICS.DISPLAY NOW, SCHEDULE A GRAPHICS.DISPLAY IN 10 
MINUTES (DAYS or UNITS) or SCHEDULE A GRAPHICS.DISPLAY AT 
1400 HOURS. This sidew-effect gives builtwrin flexibility to 
the scheduling of a display. The “GRAPHICS.DISPLAY" event 
includes initiation of inquiries and updates to the data 
base as well. Figure 3.5 depicts sample SIMSCRIPT code for 


this tyoe of subroutine call. 
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PREAMBLE 


EVENT NOTICES INCLUDE STOP.SIMULATION 
EVERY LOC.UPDATE HAS A VEHICLE 
EVERY LOS.UPDATE HAS A WHEEL 
EVERY DETECT HAS A WHOLE. TANK AND A 
DETECT.FOE ENTIRE. TANK 
EVERY TARGET.SELECT HAS A FIRING.TANK 
EVERY FIRE HAS A SHOOTING.TANK AND A 
CORE.POINTER.OR.TGT.ID 
EVERY IMPACT HAS A_ TANK.THAT.SHOT AND A 
BLOCK.POINTER.OR.TGT.ID | 
EVERY GRAPHICS.DISPLAY HAS A  COMMAND.ID AND 
ADDRESS .OF .PARAMETER.LIST 


END 
MAIN 
DREATE A PARAMETER.LIST 
LET ATTRIBUTEICPARAMETER.LIST) = valuel 
LET ATTRIBUTE2(PARAMETER.LIST) = valued 
BemeDULE A GRAPHICS.OISPLAY NOW 
BE ADO Rn eoo. Orem aARaMeteReLIST(GRAPHICS.DISPLAY) = 
PARAMETER.LIST 
END 


7) 


Svenwt GRAPHICS.DISPLAY 


® 
e 


IF COMMAND ..IO(GRAPHICS.DISPLAY) = 'I[' 
PERFORM INQUIRY GIVEN 
ADDRESS.OF .PARAMETER.LIST (GRAPHICS .DISPLAY) 
PEeCOMMAND. ID(CGRAPHICS.DISPLAY) = ‘DT’ 
PERFORM TERR ATNG OF GIVEN 


PO DRESS. OF .PARAMETER .LIST(GRAPHICS.DISPLAY) 


END 


PIGURE VS45 
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fee PREFERRED SOLUTION 

Ine the selection of the preferred alternative, those 
items designated as common considerations play an 
insignificant role. The use of color to enhance the clarity 
of the displays 1S not envisioned to introduce an additiona! 
burden on any solution. The method used to rapidly oroduce 
mumcomcour map 1S Gevice dependent and not dependent on the 
preferred solution. Ward copy ewes depengd on machine 
interfaces and are therefore implementation independent. 

It is possible for all alternative solutions to 
accomplish the sharina of date files. Database management 
systems are designed with this aoal. Database management 
Systems produce a data independence that allows each user to 
view the data in his own way. Overating systems” that 
Support seqmentation are also capable of supportina the 
sharing of data. The operating system however shares’ the 
data ina format specific manner. The distributed acoroach 
allows Bisriing of data files between the central ecrocessors 
through the use of a distributed operating system that 
mows CPU to CPU communication. The subroutine call 
approach uses common data elements through parameter passing 
techniques and global variables. 

Dynamic event recording is the first area in which 
the four approaches aiffer significantly in their ability to 
perform. All approaches are capable of recording decisions 
and saving the values of variadles at the time of the 


decision. Tt 18S not a normal database management function 
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to record and later restore the state of the machine 
registers. This interface with the machine must be made 
with the cooperation of the operating system. The operating 
System approach, on the other hand, has the interface with 
the machine registers as part of its normal operations. The 
distributed aoproach is further complicated by the need to 
Save the state of multinole CPU's and variable values in 
multiple machine memories. The subroutine call  aporoach 
suffers from the inability to directly access machine 
registers in much the same manner as the database management 
system. 

Flexibility in the level of display and the level. of 
play must be discussed in two asnects. Level of display 1s 
a function of the level of play in the fact that the only 
possible items to be displayed are those items that are 
stored. The routines written to cause the display will be 
similar for all approaches. This leaves the area of 
flexibility as a function of level of olay. The area of 
flexibility of play hinges on the ability to generate and 
Store the aopropriate data structure. This poses a oprablem 
to the database management system approach in that the 
System must dynamically generate the data structure. at 
execution time. The generation of the maximum size data 
Structure at every execution of the simulation would 0obe 
wasteful of storage. The operating system approach 1s not 
hindered py the flexibility constraint. The operating 


SyStem wil] automatically reserve storage for the data 
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Structure specified by the simulation pOprogram. The 
distributed approach is similar to the operating system 
approach in that the operating system of the distributed 
system will allocate storage as required by the 
corresponding programs. The subroutine call acproach 1s 
unaffected by the flexibility of play. By changina input 
mameameters, the user may dictate the size and structure of 
the units participating in the simulation. 

Interactive ecrogramming for the database management 
alternative is broken into two areas. The inquiry mode of 
the database system is limited only by the database 
designer. When the user asks and what he 1s allowed to ask 
are design considerations. All interactive capabilities 
other than the inquiries are limited by the programming 
lanauage concerned. The subroutine cal] acoproach mS also 
limited by programming lanauages. The onverating system 
approach is capable of fully interrupt driven processing. 
The ability to interact is enhanced by the users ability to 
write interrupt handlers to respond to user generated 
interruots. The distributed system's user programs are also 
limited by the chosen programming language. 

Reale-time processing is hindered by the database 
management alternative. The system must translate all data 
references into the appropriate addresses in order to 
complete the data references. The operating system approach 
does not affect the real-time ability of the simulation. 


The distributed system will slow the simulation due to the 
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time required for CPU to CPU communication. The greatest 
slow down will befor the subroutine call alternative since 
all processing must stop in the simulation while the 
subroutine creates the display data. 

From the above discussion the operating system 
aoproach is the only alternative that satisfies al! the 
requirements for the system. "There are several other 
considerations that favor the operating system approach. In 
the operating system aporoach the key 3s the sharing of 
data. The key data to be shared 1S generated by the 
existina simulation program. Further program development to 
Share this existing data may be done independently without 
adversely affecting the existing program. 

Another consideration is the availability of a system 
to support the simulation. Both the database management 
System and the operating system approaches deoend upon a 
complicated programming effort. A tailored database 
management system would have to be written and at best be an 
experimental system with unknown efficiency. On the other 
hand, genera] puroose operating systems capable of 
Supportina this simulation system have been written and 
tested. These proven systems are available today. 

It 1s anticipated that the simulation wil be run with 
classified imout data. All solutions to the problem, except 
the operating system approach, delegate the problem of 
Security to an external mechanism. Some operating systems 


are capable of providing security for the classified data 


71 





without depending on an external mechanism. 

The last consideration 18s the complexity of the 
momution. The operating system approach olaces the entire 
burden on the operating system to perform tasks beyond the 
capability of the programming langquaade. The database 
management system requires a complicated relationship 
between the database system and’ the operating system since 
the database management system is unable to fulfill all the 
requirements. The operating system is the only alternative 


to cerform all reauirements in a standwalone basis. 


ie 
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Ive ULUTION ANALYSIS 

System analysiS examines the existing and proposed 
software and oroduces the logical design for the system. It 
is in this phase that the intererelationships between 
modules are examined =, including determination of both 
coordination and synchronization of modules. The proposed 
Simulation system 1S composed of four programs existing in a 
mutually cooperating environment. The first and most 
important o f these four poroarams 1s the monitor program 
which is the master program that coordinates the use of the 
SyStem and is capable of initiating any of the capabilities 
of the system. A second program is the simulation orogram 
meoett. Fhis oerogram 18S the current version of STAR. The 
third program is a graphics program that oproduces all ~maps 
ana overlays to the maps. The last program contains all 
administrative routines Such aS revort writers, inquiry 
operations, all tutorials and assistance functions. The 
operating system coordinates these programs and converts 


1solated programs into the simulation system described in 


Chapter II. 


BOP eRATING SYSTEM REQUIREMENTS 

In order for an operating system to opeproperly implement 
the simulation system, it must have a number of control 
features. These required features” fall into mene four 


npomet ional areas of segmented memory, multiprocessing, 
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Synchronization of processes and segment isolation. 
1. Seaqmented Memory 

The sharing of data between user programs 1S required 
to implement the STAR model. The simulation generates a 
data file that 1s displayed by the various graphics 
routines. This data file is accessed by the routines that 
display dynamic movement, animate weapon firing, display 
impact of rounds, and display unit positions as well as 
detected enemy positions. This data must not only be 
accessed but also be updated by the routines that enable 
dynamic route and position selection and support the inquiry 
functions. An operating system capable of segmented. memory 
allows this sharing to take place (Daley and Dennis 1968]. 

A segment is a collection of information that 15 
important enouah to be given aname. A segment 1s the basic 
unit of Sharing. ASsSociated with a Segment 1S a collection 
of attributessa including a unique identifier and an Access 
Control List. The Access Control List maintains information 
specifying the processes that may access that segment and 
whether the authorized access includes any combination of 
read, wreite or execute permission. Each segment may 
consists of up to six major parts. The text section 
contains the pure unmodified parts of the object code which 
would contain the program constants as specified in the 
SIMSCRIPT PREAMBLE. The definition section contains 
nonexecutable information used by system oprogrammers in 


debugging and by the operating system in dynamic linking. 
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The linkage section contains the impure, modifiable parts of 
the object code and may be made up of two types of data. 
The links used to estabiish addresses at run time are the 
first tyoe of entry and since the memory is demand paged, 
these addresses may change. The second type of data is the 
data items from the program that will be modified during 
execution. All variables will be’ stored here. The static 
section may also be used for storaae on a per process basis 
alternately this storage may be included in the linkage 
section. A break map section contains information used by 
debuggers. The last section, the symbol sections, contains 
anything generated that 1S not stored elsewhere [Honeywel | 
975). 

All segments that are competing for system resources 
are listed in a systemmewide Active Segment Table. This 
table allows the onverating system to know which segments are 
currently active and where they are located in memory. 
Table length is finite which reauires the operating system 
to limit the number of segments capable of competing for 
SyStem resources. This limiting of processes reduces” the 
amount of time lost due to the switching of processors from 
one process to another. 

2. Process States 

A orocess iS a set of related oroceduresS and data 
underqoing execution and manipulation. Processes wil] 
Qenerally contain one or more procedure segments, one or 


more data segments, a stack segment anda linkage seaqment 
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for each procedure segment included in the process. 
Processes within a’ computer fall into one of three execution 
states. A process is said to be running if it is currently 
executing on a processor. A process is ready if it would be 
running should a processor be available. A process 15 
waiting if it cannot make immediate use of a processor since 
fees waiting tor some external (to the process) event. The 
operating system keeps track of these processes in the 
SyStem*wide Active Process Table. These three types of 
processes in the Active PiOGess Table require synchronized 
use of shared segments. 
3. Synchronization of Processes 

In order to synchronize processes some method of 
communication between the processes must exist. This 
interorocess communication is monitored by a mechanism known 
as the traffic controller which functions as a ageneral 
Burpepcse supervisor for control of parallel operations (Daley 
and Dennis’ 1968). Two of the more interesting mechanisms 
provided by the traffic controller are the block and wakeup 
Pare tyvOns. The block function forces a Process to wait for 
an occurrance of an event generated by some other process 
while the wakeup function allows the process to be notified 
that the event has occurred and processing may resume. This 
blocking of a orocess 18S recorded in the Active Process 
Table. 

Another mechanism used in Synchronization 1s a 


condition handler. Users and orocesses may Communicate with 
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processes through the use of condition handlers. Condition 
handling refers tO an activity resulting from a hardware or 
software condition named by the user's proaram. The user 
may implicitly or explicitly identify the code to obe 
executed in response to the condition. To initiate user 
interaction with the simulation, the programmer specifies 
the pressing of the ATIN key on the terminal keyboard as a 
hardware condition. In response to this condition, 
execution control is transferred to a condition handler 
which contains code to request the type of action required 
by the user. The user oerforms his desired interaction and 
the simulation resumes execution. Condition handling need 
not be a riaid response to the specified condition. The 
programmer has the option to specify condition handlers on a 
segment by segment basis since condition handlers are pushed 
onto a stack as they are defined and popped from the stack 
when the procedure seqment for which they are defined is 
exited. In this manner, the programmer may specify a global 
condition handler as the general response to ae aqiven 
condition and redefine the response to the condition on a 
procedure by procedure basis should the response change for 
each particular environment. Should the response to the 
condition be the activation of another orocedure, the 
condition handler then becomes another of the deliberately 
Meeperating Procedures. 

Deliberately cooperating programs or procedures” may 


interact through the use of interrupts which are synchronous 
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events internal to the machine. When one procedure desires 
Bo call another procedure, the calling procedure generates 
an interrupt. The key to flexibility in interrupt handlina 
iS to convert this interrupt to a wakeup. The interrupt is 
sent to the interprocess communication controller which in 
turn sends a wakeuo to the called procedure. This called 
Beeceoure is then activated and execution may resume. There 
iS no problem with simultaneous use of a procedure by 
multiole calling procedures since all references to the 
called procedure are made via the calling procedure's 
linkage segment. Once the called procedure has completed 
execution, the called procedure places itself in a blocked 
Status to await further use (Graham and Denning 197e]. 
Coordinated sharing of writable data segments may be 
handljeq through a lock mechanism provided by the operating 
System. This lock mechanism is applied to a data seqment 
whenever that segment is being utilized by a orocess capable 
of modifying its contents. Further attemots to reference a 
locked segment will be denied until the segment is unlocked. 
The lock mechanism blocks the process that is attempting to 
use data segment and maintains the identification of the 
requesting process ina list structure. Once the segment 
nas been updated, the locking mechanism sends a wakeup to 
the next process selected to use the datar, unlocking the 
data segment for that process. [his procedure 1S repeated 
until all requests are fulfilled and the data seament ee 


unlocked to await future use. 
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4. Isolation Techniques 

Interprocess isolation is accomplished through the 
Access Control List discussed in section Ael of this 
Chapter. Intraorocess isolation is imolemented through the 
use of concentric protection rings where a ring bracket is 
associated with each segment. The ring bracket 1S an 
ordered triole <Ri,R2,R3> which soecifies the access bracket 
<R1,R2> and the call bracket <R2,R5>. These two subsets of 
the ring bracket dictate the reads write, execute and cal] 
access for that segment. A procedure may execute in any 
ring from Rt to Re inclusive and may be called by any 
procedure in rings (R2 + 1) to RS inelusive, provided the 
calling procedure has sufficient security clearance. A data 
segment commonly has Re equal to R3 since calling ae data 
segment has no meaning. A procedure segment may write to a 
data seament in rings 0 to RI inclusive and read from a data 
segment residing in the region 0 to Re inclusive. Again, 
read and write access are denied to any segment 1n any) ring 
that does not have sufficient access granted in the Access 
Control List. 

A segment may also have a security level associated 
myth iit. This security level 1S composed of two parts, 
Security classification and security category (Schiller 
m7s). The security classification is a type of 
compartmentalization similar to the Department of Defense 
security classifications secret, confidential, etc. This 


Security classification is a totally ordered set where 


79 





secret is strictly greater than confidential and so forth. 
The second part of the security level is the security 
category Sarr 1s a modifier to the security classification 
and analogis to the Department of Defense categories of 
crypto, NATO, etc. In addition to access granted by the 
Access Control List, procedures must also have an 


aopropriate security level in order to gain access. 


B. ANALYSIS OF ENHANCEMENTS. 

Certain design characteristics must be followed in the 
eesavon of ai!) software for the proposed system, Al] 
software developed should be easily portable, avoidina 
locally produced library functions since they may not exist 
at another installation. All modules should be human 
engineered to permit easy use. Operator inputs should be 
minimal and concise with default values orovided for al] 
modes, Paimanaten ¢ and variables. These defaults lessen the 
burden on the user and facilitate the requirement. for 
minimal inout. Additionally, defaults reduce the number of 
user errors. Maintenance responsibility for the software 
must be charged to a specified individual oF Grove. of 
knowledgeable individuals. All graphics routines developed 
should comply with the new graphics standards under 
Gevelopment by the American National Standards Institute 
(Newman and van Dam 1978), 

In addition to the existing simulation program, several 


new modules and separate erograms must be written to achieve 
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the type of interactive simulation described in Chapter II. 
These additional modules and programs include all graphical 
diselaysr inquiry, synchronization and report generator 
functions. 

The choice of utilizing the onverating system approach to 
implement the Simulation System has facilitated the 
programming effort required. The’ area of flexibility of 
play no longer concerns the proaqrammer. Storage for 
variables is automatically allocated as a normal function of 
the operating system. The orogrammer does not need to 
concern himself with an elaborate data structure that 15s 
capable of growth since this burden 1S assumed by the 
operating system. Fliexibility of display becomes a oroblem 
of searching for all the elements of the unit being 
displayed and then using some appropriate weighting factor 
to properly position the unit symbol. 

Programs may be developed independently ont the 
simulation by using simulated data files and therefore not 
hinder the use of the simulation or require duplicate copies 
of the simulation program for developmental ourposes. When 
the additional programs are tested and Oronounced ready (for 
uS@r, the only action freauired is to inform the operating 
System to allow access to the Shared data files. 
Synchronization of use of these shared files is required but 
mechanisms discussed in section Aw~3 of this chapter allow 
this synchronization to occur. 


1. Interactive Programming 
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The area of interactive programming may be broken 
into two sections. The user may interact with the simulation 
program as well as the individual Simulation programs 
interacting with each other. The case of the user 
interacting with the simulation may be satisfied by the use 
of Bendition handlers while individual programs cooperating 
with one another may be accomplished through the use of 
interrupt handlers. 

An example of condition handling may be the 
implementation of dynamic route selection. When the light 
pen is activated, a hardware condition occurs and execution 
control 1s transferred to the condition handler, The 
condition handler sends a wakeuo to an updatina procedure. 
This wuodating procedure accesses the data and places a lock 
on the data segment. This lock prohibits the use of the 
data while it 1s being updated. When undating is completed, 
the lock iS removed, the update procedure places itself in a 
blocked status to await itS next wakeup message, the 
condition handler is exited and execution resumes. 

Use of coordination by interruot handling may be seen 
in the dynamic updating of positions. When the movement 
module cnanges the location of the unit, an interruct 1S 
generated as the movement module is exited. This itnterrupt 
1S converted into a wakeup that is sent to the display 
routine. The display routine creates the new display and 
then olaces itself in blocked status to await the next 


position change. This conversion of interrupts to wakeups 
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not only facititates display but also allows the procedure 
to be active only- as required. Extraneous nonexecuting 
simulation routines need not be in primary storage until 
required for use and disolay routines need not continuously 
draw the same picture in order to prevent missing an event. 
Displays may now be made only as change occurs. 

2. Real-time ——- 

Real=time must be aporoached from both the computer 
Sclence and modeling definitions. The computer science real 
time i$ accomolished by the synchronization mechanisms 
discussed in section A-#-3. The various programs) and 
procedures are forced to run in=steo since they are called 
by wakeups from the main simulation on an as required basis. 
This system will have least overal|) detriment to the 
simulation in the modelina real-time sense. Memory 
management may prove to slow the simulation from paging 
activities but proper selection of the orogram's working set 
Size will reduce these oaqing delays to a minimum (Denning 
708). A clever operating system wil! have facitities for 
maintaining the current working set size aS a program 
executes. Associative and cache memories wil! also seeed uo 
execution of the simulation execution due to hiaqh~ speed 
address translation and reference (Schroeder 1971]. The 
mechanisms to synchronize segment usage may cause some 
Slowing while procedures are in a blocked status. This 
slowdown will be overcome since separate programs will be 


allowed to execute simultaneously in a multiorogrammina and 
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multiorocessing environment. An example of synchronization 
of segment usage is the calculating line of sight while the 
display of current positions is being oroduced by another 
processor. 

3. Monitor Program 

The monitor program provides a master Coit ia)! 
facility for the modeler. This monjtor program provides the 
main condition handler for the simulation. From the master 
console, any capability of the simulation system may be 
called at any time. Any privileged instructions available 
to the modeler but not the war gamer will be executable from 
this terminal. 

The monitor program will be written aS a Separate 
program executing on a dedicated display device. Aj] 
modules of the monitor program will pe wor sufficvent 
oriority to preemot any of the executina routines of the 
other programs. of the system. 

Tne monitor program is made possible through the use 
of condition handlers and shared data. The monitor program 
will also be capable of placing locks on data files since it 
is capable of writing to data files. Coordination with the 
remaining procedures will be accomplished through the block 
and wakeup mechanisms. The access rights and security 
levels of all procedures will be set by the monitor proaram. 

GQ. Dynamic Event Recording 
Dynamic event recording is used to save the execution 


State of the simulation at various decision making points. 
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fs State of execution is composed of two distinct parts 
with distinct characteristics. The state of the simulation 
is the set of values of all simulation variables. Whenever 
a decision 1S input, the operating system needs to copy the 
data segments containing the aporopriate variable values 
onto a secondary storage device. These values must be 
copied prior to any changes due to the input decision. The 
State of the machine is characterized by the values in the 
machine‘s internal registers. At the decision opoints the 
operating system saves the register values in secondary 
storage. The operating system must then label these values 
and inform the user of the assigned label and resume 
execution. At some future time when the user desires to 
return to this pointer he need only supply the label value of 
the decision point and the operating system wil] then 
restore the simulation and execution states, returning 
control to the user for his new decision. 
5. Report Writer 

The purpose of the report writer is to produce 
Statistical] reoorts based on stored historical data and 
Sulememt Dattle status. It should have the capability to 
produce graph summaries of the user's desired format. For 
instancer bar grapns may be desired over simple plots’ for 
certain items. For ease of implementation, this should be 
defineo as a user requirement however the report writer can 


be developed with sufficient flexibility to allow 


interactive user format selection at the expense of laraer 
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programs. If sufficient storage space (memory or secondary) 
exists and system execution 1s not sufficently degraded, 
then this flexibility should be pursued for the benefit of 
the ultimate user. 

The report writer is a procedure included in the 
administrative routines program. Proper selection of ring 
brackets and delegation of access permission will allow the 
report writer to reference data and perform its required 
function. The report writer may be invoked from either the 
administrative program or the monitor program. The itnvoking 
program sends a wakeup to the report writer to initiate the 
procedure. Upon completion, the report writer places itself 
in a blocked status to await further use. 

6. Inaquiry Mode 

The function of the inquiry mode 1s_ to allow 
commanders and their staff sections to auestion the 
simulation. Legitimate inquiries are those that eacn agency 
would normally initiate during an actual battle. Pehe 
Instance the S-1 would not be allowed to query directly the 
status of some area outside his cognizance out rather 
require him to communicate via the appropriate agency which 
has cognizance over the area in question. Chapter II, 
section D previously identified normal areas of cognizance 
mer the staff sections. 

Answers to any agency's request must reflect the 
accuracy and timeliness exoerienced in a true battle. This 


requirement should be handlied in the simulation of inter= 
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organizational communication oaths. Any accurate and 
instantaneous reply could be misleading to to the commander. 
Human factors must be considered and accounted for in the 
inquiry mode's operation to reflect realism. 

7. Map and Overlay Generation 

Initial terrain generation experiments were conducted 
on a PDP 11/50 using a TEKTRONICS 4014-1 display device as 
the display medium. The 4014 has several display modes 
including point ' and vector. A resulting tutorial was 
developed for use and 1s included as APPENDIX A. 

Current methods used for generating contour maps from 
stored matrices of data could not be used to display the 
mamreaim for this simulation (Dayhoff 1963). One of the 
advantages of oOarametric terrain is that terrain may be 
calculated rather than stcred allowina large areas to be 
modeled. Using calculated terrain, the only altitude known 
beeehat of the current location. The decision was made to 
scan the area from South to North and from West to East to 
determine the location of contour lines. The resulting 
problem was that with a constant samoling step size, it 
could not be guaranteed that the step taken would in fact 
fall ona comtour line. Next a point was accepted as being 
On a Given contour line if it were within a specified 
tolerance from the contour line. This tolerance was 
measured in the vertical direction. The first attempt. at 
displaying parametric terrain utilized the point mode of the 


4014, The deficiency noted in this aoproach was the 
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inability to establish contour lines since the display image 
consisted of a series of dots. To accomplish the illusion of 
lines a sufficiently small delta x and delta y had to be 
used thus extending execution time for any given piece of 
terrain. I1f the display wasto be maqnified to any degree 
the line illusion became visible dots or points once again. 
This effect demonstrated the need to draw contour lines 
uSINng the vector mode of the 4014. 

In order to utiltze the vector moder, a drawing 
algorithm was developed. The algorithm used to determine 
the direction of draw was quite simole. Once a decision to 
draw was made, all ooints adjacent to the current point in a 
North or East direction were calculated and the line was 
drawn to the point closest to the contour elevation. This 
apProach produced contour bands rather than contour lines. 
These bands were acceptable on steep slopes bdut in the 
flatter areas they were quite wide. An attempt to reduce 
the number of line segments to be drawn was made by drawing 
to a given ooint only if the ooint immediately North of it 
was farther from the contour line than the current point. 
This produced contour lines that were shaded on the North 
side. The solution to this problem resulted in an 
additional condition that a point would not be considered 
for plotting unless it were closer to the contour line than 
both the adjacent points in the North and South directions. 
The resulting map was adequate but still retained shading 


along a hill's major access in the area of the contour line 
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plus and minus the tolerance. The shading was negligible 
near the peak of the hill, but quite distracting near the 
base. The shape given by the distribution is tncreasinaly 
flatter as one proceeds outward from the center of the hill. 
The solution to this problem was in the calculation of a 
dynamic tolerance. This tolerance was calculated by 
determining the distance from hill center that the 
distribution reached three standard deviations or fell below 
some specified minimum altitude, whichever comes first. 
This method produces an acceotable map. The resultine 
algorithm follows: 

1. Locate point closest to contour line. 

2. Sample adjacent points to North and/or East. 

SeeoGewe line to adjacent point closest to contour 

line. 
4. Locate next coint closest to next contour line. 

The major drawback to this approach lies al 

consumption of time. This method is of complexity of order 
N squared meaning that doubling the size of the map to be 
displayed roughly quadruples the execution time. This 
routine 1s by no means realetime in nature. Experiments 
were conducted to speed up the drawing of this contour map. 
The map may be drawn in realetime if the calculations are 
Mot required every time the terrain 18 displayed. The 
solution requires that the commands to move and draw that 
are generated by the CPU and sent to the display device must 
be intercepted and written to a data file. Uoon a request 


to draw a given arear only the actual move and draw commands 


need be executed. These commands may be created and Stored 
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as the terrain 1s designed and referenced later during the 
simulation as required. 

The ability to draw different sections of the 
battiefield is easily attained. By using a device such as 
the TEKTRONIX 4014 a virtual window may be defined to the 
display. This virtual window 1$ mapoed onto the physical 
display window and only the points within the virtual window 
are displayed. This virtual window may be dynamically 
created from inout parameters from the console. The contour 
lines may be stored in separate files per individual line 
elevation thus allowing combinations to be plotted and 
Qiving flexibility of selection of line interval. 

fwenraycseai!) be plotted on the basic contour map. 
These overlays may be selected individually or in any 
combination of the available overlays. The use of color 
gisolays will make the overlays stand out from the map and 
avoid confusion when multiple overlayS are requested. In 
order to avoid destruction of the contour map by overwriting 
from the overlays, the display terminal must’ have a 
selective erase capability. This will allow the removal of 
a specific overlay without disturbing any others that may be 
disolayed at the time of removal. 

8. Security of Classified Data 

Physical security of the classified data durina input 
or output remains the problem of the user. The terminals 
used must be in a secure environment to avoid compromise 


before data 1s entered into the comouter and after the 
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classified output 1S generated. Remote use o f the 
simulation will be’ possible if scrambling devices are placed 
on the communication lines. Computational security 1s 
orovided by the operating system since properly specifying 
the security level of the simulation will cause the interna] 
protection mechanisms to safeguard the data from tampering 
within the computer. Thus the stmulation running classified 
data may be described with a security level of 
<clearance,STAR> and thereby refuse usage of the data to 
anyone regardless of classification without STAR access. 
9. Library Routines/Tutorials Needed 
In any interactive system certain library routines 
and tutorials make the system more convenient to use. These 
routines lie resident within the system and are capable of 
being called by the user. Several readily identifiable 
examoles are discussed in the following sections. 
Si. Terrain Generation Package 

The purpose of the terrain generation vdackage 1S 
to allow the user to define any aiven terrain area in terms 
of the required parameters prior to the execution of the 
battle simulation. The terrain generation package uses the 
identical data items required by the elevation routine of 
the simulation. Once the user has defined the terrain to 
his satisfaction he can elect to creat a file containing the 
display device commands generated during the display phase. 

The terrain generation package includes two major 


}tems, a hiahly interactive orogram and ae tutorial 
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describinq the program's use. The interactive program 
allows the user -to define ana display the terrain of the 
battle area. The definition phase includes capabilities to 
builds, modify, add-to or delete-from a data file containing 
the oarameters. Appendex A defines these allowable 
functions. 

The terrain display phase allows the user to draw 
contour lines of his chesen level from the data. The user 
specifies bounds for the display in terms of maximum and 
minimum grid coordinates, the contour level and the steo- 
size desired. The user svcecified bounds give the illusion 
of zoomingwin or away from the terrain. Bounds smaller than 
the defined battle area wil! cause a smaller area to be 
disolayed in the static display window creating a blown-up 
or zoom-in effect. Conversely, should bounds laraer- than 
the battle area be orescribedr,/ a reduction or zoom-out 
illusion is created. All displays are generated without the 


need to store in memory an elevation for each <x,y> 


ocation. 

The terrain aeneration orogram contains the 
following functions. The user is allowed to build the 
parametric data file under a filename of his choosing. He 


1s allowed to add, delete and modify the file to reflect the 
Cufrent state of terrain generation. There should be a 
Narrative portion which describes the function of the 
program and demonstrates effects of different input 


parameters. The user should also be allowed to familiarize 
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himself with the system by manipulating parameters and 
seeing the results displayed. The capability to plot 
contour lines of the user's desired contour level from the 
defined terrain is also provided. 
be Position Selection 
The purpose of the position selection package is 


to 
routestof-march for his 


terrain generation package, 


Set-up operation designed 


battle. Execution during 


insight as to possible new 


battle orogresses. Since 


simulation is provided for, 


information gleened 


forces. 


the user may desire 


allow the user of STAR to select defensive positions and 


This oackage, like the 


is primarily a prewexecution or 


to facilitate olanning of a 


the battle will give the user 


positions or tactics as the 


interaction between user and 


toe uty lize 


from the position selection package to 


perform updates during the simulation. 


The, position selection 


eontour 
determine linewofw=sight (LOS) 
metmim the battle area. 


representation of LOS fans, 


each with 


orogram should use the 


map generated by the terrain generation package and 


fans for any selected position 
There are two approaches to the 
advantages 


it's own 


and disadvantages. The first approach is to shadew-in the 
viSable area in the fan. This method gives the user a 
distinct impression of how much area the fan covers. 
However, specific terrain characteristics within the fan may 
be hidden from the user's view. To counter this 
degredation, the oackage should allow the user to display 


oe 





the fan in an inverted mode. This inverted mode should 
shade the areas outside the LOS fan thus allowing the user 
to see only geographic features defined within the fan. 
These two approaches when combined should allow the user al] 
LOS related information concerning that position. Fiaures 


4.1 and 4.2 depict the results of the two methods. 
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ce. Military Symbol! Library 

The ourpose of the military symbol Ijorasy is to 
allow the user either through his interaction or program 
action to select a series of oredefined display device 
commands to draw a standard military symbol. This functions 
somewhat like a table lookup orocedure where the resulting 
table entries are a series of  ,entries that define a 
particular symbol. The map overlay disolay programs must be 
able to access this library and retrieve these instructions 
for dynamic display during the battle. 

Military leaders are innovative wnen a standard 
symbo!] has not deen defined for some uniaue apolication and 
consequently establish some symbol to reoresent their new 
weapon or unit. The orogram should allow the user to define 
any additional symbols needed. A standard checker-board 
pattern, such as figure 4,3, Should be orovided on the 


Gdisolay screen. 


eS @S& eee eee. e@eeeqade @ east wes & ae @ & od 


0 0 q L 0 q f { t 1 t 
t q t t ] { " t ‘ L] ’ 


L 0 0 0 0 ] L 0 t q 0 
t ’ ’ L ’ t t { q f 0 


0 0 q 0 t ] 0 1 Q t ‘ 
$ + { 0 { § , 1 1 i) 0 


figure 4.3 
The user can select any square and the prooram will shade 
that area. By continued selection, the user can define a 


Symbol of his choosing. After the user has defined the 
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symbo| to his satisfaction, the program should display the 
symbol for final aporoval of size and features. The symbol 


may now be stored in the library for future reference. 


meeeoe OF THE SYSTEM 

The simulation system will be useful in all phases of 
modelina. A typical senario re follow this outline. The 
life of a simulation beaqins with the writina and debugging 
of the code. The simulation imolementer may sit in his 
office and enter the code throuaqh a console as opposed to 
punching data cards and feeding them into a card reader. As 
the implementer PR hee entering the code, he may now 
compile the program and correct any syntax errors from the 
console. Execution may reveal oroblems with his code that 
may also be corrected from his console. 

The user of the simulation takes over after the 
implementer has finished and the model is ready for use. 
The user must first set uo tne model for use. This set up 
1s facilitated by the tutorials provided by the system. The 
terrain generation package exolains the method of generating 
terrain. The user uses this terrain oackage to generate and 
store the parameter values necessary to create and display 
the terrain. Using the linerofesight capability of the 
System, the user then selects the initial positions for the 
elements on the battlefield using the LOS fans provided by 


the system. 


The modeler iS now ready to use the simulation. AS the 
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simulation progresses», the user 1S able to monitor the 
simulation and decide when to interact with the simulation. 
Should he decide to interact, he may do so from his console 
by pressing the ATTN key and selecting the type of 
interaction desired from the menu of possible alternatives. 
Once the interaction iS accomolished, the Simulation 
continues. fhe user notes the effect of his interaction and 
wonders if the outcome would aheaoe had the interactive 
meet been different. He elects to return to the point of 
input and experiment with a different course of action. 
Againe he presses the ATTN key and this time ne chooses the 
option to repeat the simulation from a specified point. 
Having changed his inout, the user elects to continue with 
the simulation. The simulation continues until termination. 

Post execution analysis 1S accomolished throuqh the 
creation of written reoorts by the report writer and the 
answering of questions by the mnquiry routine. At this 
Point the caer may still elect to investigate behavior by 
returning to a given point and resuming execution. Upon 


completion of analysis, the user may elect to destroy tne 


Simulation files. 
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Veeco vols .0F CURRENT STAR 


A. GENERAL 

The analysis conducted on the current version of STAR 
was performed in the general areas of program structure, 
contro] structure, storage optimization and subroutine 
analysis. Certain quidelines were used in the analysis of 
the current version of STAR. The proaramming language used 
mse SIiMSCRIPT. The methodology used in the simulation wil] 
be left to the programmer and comments will be limited to 


programming techniques. 


Seo TRUCTURE 

The SIMSCRIPT programming lanaquage has the capability to 
be both readable and structured. Readability and structure 
allow the program to be maintained by persons other than the 
original writers, iii Cabaobility of the language is not 
being fully exploited. Good readanility facilitates ease of 
maintenance and debugging. To attain the desired level of 
readability several principles must be followed. 
Indentation should be oresent to offset the control 
meructure from the code that is contained within that 
Structure. For example, should the "if" in an "if else" 
Structure be indented five spaces, the “else” should also be 


indented the same numoer oy i spaces. Only one source 
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statement should be allowed to a line. All local variables 
should be defined rather than allowing the default values of 
SIMSCRIPT to take precedence. Variable mames should be 
obvious aS to their representation, since SIMSCRIPT allows 
long variable names. Many cases of short variable names 
occur in the STAR orogram either through ease of use or bad 
programming practices. These shorter eres contribute to 


ambiguity and confusion. One example of lack of structure 


is seen in the following code extracted from the current 


models: 
Umti] fj31 = 1, do 
let target (name(tank),2) = he.draaltank) 
let he.drag(tank) = 0 let mv.state(tank) = 1 
let defnum(tank) = 1} 


let jji = jj + 1 loop 
This code wil] be more readable it ret were structured 


similar to the following: 


until jji = 1, 


do 
; let target (name(tank),2) = he.wdrag(tank) 

let he.drag(tank) = Q 

let mv.state(tank) = 1 

let defnum(tank) = I! 

bee Fj) y= jjt + it 

loop 

This type of structure has two major benefits. Programmers 


eaSily recognise the scope of the UNTIL statement and the 
assignment statements are readily found since they are one 
per line and begin with the reserved word LET. 

Another example of how structure may lead to 
understanding is found in the following segment of code from 


the routine CHG.SEC.SEARCH. 
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Giese 
if ess(a) = 1 


Go tomd! | 
else 
go to died 
die (i la 
let pri.dir(a) = pi.c/2 


let css(a) = 0 
qo to set 
Scie” 
retm2zyx = Umniform.f(0.,1.,!) 
lnweezyx Oe .5 


qo to di 3 
else ‘ 
Gomto dia 
"g13" 
Letmeoriecir(a) = pi.c/4 
let essa) = 1 
go to set 
seo 
bee ori.dir(a) = 3*p1i.¢c/4 
let essa) = 1 
go to set 
"set" 


Upon examining this unstructured version of STAR source 
code, it is evident that it may be replaced by the following 


sequence: 


ere | oul 
iemecSscita,) = i 
feemoeiwedir la) = 01.¢/2 
let essa) = 0 
go to set 
else 2 
let ess(a) = 1 
if uniform. f(O0.,lerl) ge Tis 
fet. or1.dirla) = pi.c/4 
go to set 
else 
let oriedirla) = 3xpi.c/4 
“set * 
This code sequence is easily understood ana has ~ two 
additional] benefitse First, this Structured code will 
execute faster due to fewer transfers of control. Second, 
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storage requirements are reduced since this version has 
fewer lines of source code - thirteen instead of twenty- 


four, thereby reducing object code storage requirements and 


does not require the variable " 


C. CONTROL STRUCTURES 
The STAR model needs extensive optimization in the area 
ee 6ccontrol Structures. The following example is from the 


routine COMMO.PASS.TGT. 


iWimpetevi1s Qt critical.value 
let lose = 1 
jump ahead 
else 
let lose = QO 
here 
if lose eq 0 
let aim = Q 
return 
else 


This code sequence is equivalent to the following: 


1feoet.evis ie critical.value 
let aim = Q 
return 
e|lse 
The sequence may be reduced even further nat the variable 
aim" is initialized to zero since this 1s the majority of 
usage ("aim" is set to zero four times as opposed to one 
only once). This saving in Storage of object coder ease of 
understanding and execution speed-uo 1s attained by testing 


“less than or equal to" as oreposed to “greater than". This 


particular tyoe of control structure 18S used 1n other places 
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in the program as well. 

Another common contro! structure abuse is observed in 
the routine RES4. This routine has seven "do loops", all 
indexed from 1 to e. These loops may be combined into one 
control structure which wil] result in a reduction in 
execution time (counter maintenance) and a saving in object 
code storage. The combination of "do loops" is possible in 
the majority of the STAR routines. 

Another optimization technique acolies to the routine 
PRIORITY.AND.ROUND.SELECT with the follwing code sequence: 

let 121 2 1 
go to o> 13, Ol, i9, ile per 1 
eA") 4 

let 7 = Q 

go to bands 
ae Va ad 

let i = 3 

go to bands 
oO. 

let 1 = 6 

.go to bands 

"79% 

let 129 

go to bands 
Swale. 

let i = ie 


go to bands 
"hands" 


A little “cleverness” reduces this sequence to 

imaeti - 2) * 3 
Mmoumeract, in this routine alone, fifty~four lines of source 
code may be reduced to four lines without loss of meaning. 


Benefits of the reduction include ease of understanding, 


more efficient execution and less storage requirements. 
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D. STORAGE OPTIMIZATION 

Storage optimization can occur in several ways in the 
STAR model. Appendices C and D present the storage 
requirements of the current unstructured model. The 
“complexity” item under each routine analysis in Appendix B 
indicates storage dependencies. 

Another area that deserves .close monitoring is tne 
assignment of subscriots in arrays. An example of this 
detrimental effect is seen in the array called TARGET. The 
actual variable is TARGET( 321-2). SIMSCRIPT creates a data 
Structure with $e! pointers to vectors of length e. By 
reversing the subscripts giving TARGET(2,5321) the SIMSCRIPT 
compiler stores this with 2 pointers of length 3el. This 
reversal of subscriots saves 319 words of storage or 12/78 
bytes of memory. I[f at all possible, suoseriopts should be 
arranged with the smallest first and in increasing order. 

Appendix D gives a summary of all static storage arrays 
and the storaaqae required if an optimal assignment. of 


suobscriots is used. By this use of optimal SUDSCiInvO. Ss 


approximately lek bytes of storage may be saved. 


Seo rMOoCRIPT ROUTINE ANALYSIS 

The SIMSCRIPT routine analysis was performed after a 
Structured version of STAR was produced. All names are 
alphabetical within their category. For each subroutine the 
following items were identified: 


1. Parameters oassed to the subroutine. 
tA 
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Loe 


Local variables defined to that subroutine. 
Global variables accessed. 

Variables read into the subroutine. 
Variables written to print. 

Data structures created. 

Data structures filed into a predefined set. 
Data structures removed from a set. 
Data structures destroyed. 

Vectors or matrix for which storage is 


reserved. 


Vector or matrix for which storage is released. 


Other subroutines called. 

Subroutines that call the subroutine. 
Events scheduled. 

Subroutine that schedules the event. 
Complexity of subroutine in regara to 
execution time and storaqe requirements. 
Recommended imorovements (excluding genera] 
improvements identified earlier). 

Any remarks concerning the subroutine and 


values returned to the calling porogram. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


The STAR war gamina model is written using sound 
modeling techniques. The imolementation does have a serious 
drawback in maintainability. Without Strcucuune, this 
program is difficult, at best, to understand and will be 
extremely difficult for anyone other than the actual code 
writers to maintain. The current version of STAR is at this 
time undergoing extensive modification to give the program 
structure and to attemot to again efficiency to both storage 
and execution. 

This thesis 18 a oreliminary desian and therefore only a 
oreferred solution was given. As the preferred solution is 
developed at a later time, more detail may be given as to 
the fina] implementation oO f the STAR moacel. The 
implementation-of STAR using the operatinaq system approach 
may be attempted here at the Naval Postgraduate School. The 
features described that are necessary to implement the 
Proposed enhancements are found in the MULTICS operating 
SyStem from Honeywell] Information Systems, eGre which 1s 
available on the ARPANET. This availability gives the 
scnoo!l the opportunity for further study. 

One of the most beneficial short term improvements that 
can be made is to obtain an interactive SIMSCRIPT compiler. 
The interactive comoiler may be obtained free of charge from 


Consolidated Analysis Centers, Inc. under the university 
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grant orogram. 

Furtner experimentation with graphical displays may be 
made at the Naval Postgraduate Schoo!) utilizing the research 
comouter in the school graphics laboratory. This comouter 
may be used as a remote terminal to the wWeR. Church Computer 
Center and graphics disolays oroduced on the terminals in 
the laboratory. 

The STAR wargame orovides excellent opportunity for 
further computer science thesis work. Additional thesis 
material may include optimization of terrain disolay using 
the parametric method of terrain reoresentation. Thesis 
work im the area of operating systems may include actual 
implementation of the STAR model on the ARPANET. Work in 


the database area wil] be required to develoo the mmquiry 


capability and tne reoort generator. 
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APPENDEX A 


AN INTRODUCTION TO INTERACTIVE TERRAIN REPRESENTATION 


UTILIZING PARAMETRIC TERRAIN GENERATION 


I. INTRODUCTION 

This tutorial has deen develoned to allow interactive 
use of parametric terrain aeneration. Currently mechanisms 
exist for ouildina and modifying the inout file required for 
the aeneration of terrain features and displaying contour 
lines of tne user's desired level. Due to modular design, 
further terrain enhancements such as three=dimensional views 
from any point may be develonved and incorporated into the 
existing program. 

Parametric terrain generation uses 82S inodut parameters 
the x and y locations of the center of the hill (xe and ye), 
the elevation at that <xcryc> location (peak), tne 
eccentricity of the Hiecece), the heignt of the 
Parameterized hill (ht), the anale of rotation of the hill 
from an East-West axis (angle) and the spread of the hill 
(sprd). For each set of hill values there is a base 
altitude/elevation (foasealt) associated. fhis base altitude 
1s the elevation of the lowest point in the terrain area 
that is being modeled. The eccentricity of the hill (Cecc) 


is tne ratio of major axis to minor axis (majorwaxis/minore 


axis) for the hill under consideration. The spread of the 
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hill is considered to be the distance along the majorwaxis 
for the elevation-to drop fifty (50) meters. Figures Aj-i.l 


through A-1.5 graphically explain these parameters. 


FIGURE Aw-1.3 
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II. HARDWARE REQUIREMENTS 


A. INTRODUCTION 

The display hardware utilized in the develooment is 
centered around the TEKTRONICS 4014-1 storage tube granhics 
display system. It has a 19 inch storage tube as ai display 
medium. Associated with the Word 18 a Standard ASCII 
keyboard. 

A VERSATEC MATRIX crinter is accessable through the 
PDP 11"50 and allows hard copy generation from the 4014 
disolay. A hard copy of the 4014 display screen can be 
obtained by depressing the cooy key locateaq on the upper 
right portion of the keyboard. 

Tne PDP 112*50 with the UNIX timesharing system is 
utilized and assumes the 4014 18 a conventional alphanumeric 


mee allowing the user to "login" normally. Section IV 


Giscusses these “login” procedures. 


peeorslTEM OPERATION 
The 4014 is powered on by turning the offson switch, 
located under the keyboard about one foot from the floor, to 
the on oosition. After turning the device One wait 
approximately 30 seconds before proceeding to allow the 
Gevice to warm up. The screen will appear a bright green and 
NOw must be erased by depressing the page reset key on the 


upper left portion of the keyboard. Should a residual image 





appear on the screenr wait aoproximately 15 seconds and 
deoress the page reset key once again. Insure that the mode 
toggle, located above the page reset key, is 1m the online 
position rather than local. Depress the carriage return and 
walt for the UNIX timesharing System to request "login". 


Follow normal PDP 11°50 login procedures. 
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IIIT. DESCRIPTION OF PROGRAM FUNCTIONS 


A. MAIN 

The main program requests the name of the data file 
that the user desires to operate on during this terminal 
session. Jhe user enters the filename, upon request in 
either upper or lower case letters, that he either desires 
to use or create. The filename is limitea to eiaht 
characters but the user may specify any length filename and 
the program will only use the first eight, terminating all 
others. For this reason the first eight characters of any 
filename should be unique. [If the filename iS not. an 
existing file, the program will create it for the user. If 
the file does exist, the program will open that file for 
read and write access to the user. A command list 1s 
displayed next to allow the user to select that function he 
desires and enter the aopropriate command code when cromoted 
Dy the program. The main program is developed around a CASE 
Statement EO allow the user to oserform his desired 
functions. Control remains in this CASE statement until the 
user elects a code of "7" to terminate the session. When 
the user selects code 7 the program displays the current 
State of the data file that the user selected during the 
beginning of the session on the 4014 and uodates the _ file 
mor future use. Shoula the user not desire to retain the 
Current copy of the file, he may exit the proaram by 


depressing the rubsout key located on the lower right 
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portion of the keyodoard. (This method of orogram termination 


i$ not recommended -as a shortcut however.) 


B. ADO 

The add function allows the user to add another set 
oy) ies values to the data file specified in the beginnina 
mrethis terminal session. ee tae of hill values is 
accomplished by adding them to the end of the data and 
incrementing the number of hills on the file. The program 
will prompt the user far each data item required for the 
hill and give the user the option of adding multiple hills 
or only a single hill. All nild values are floating point 
numberS, however, the user need not specify a decimal ooint 
1f that value is a whole number since the program is capable 


of interpretation in this case. 


me BUILD 

The build function gives the user the capability to 
initially build the file snecified during the beginning of 
the terminal session. Care must be taken to prevent 
building a file that already exist since the buildina 
process will overewrite all data oreviously resident on that 
mr le. Building is accomolished by requestina from the user 
the number of hills he desires to load to the _ file. Next 
the orogram will prompt the user as in the add function for 


all neccessary hill values. The orogram will allow the user 


to only build one file per terminal session. However, 
should the user desire to duild multiple files he may do $0 
by building the first one and then enter a command code of 
me to exit the proaram. Subsequent file buildina is 


accomolished by repeating this same procedure. 


DO. CHANGE a 

The chanae process 1s actually a modify erocess since 
it allows the user to change or modify any sinaqle hill data 
item or all data items for a hill. The program promots'7 the 
user for the hill number he desires to change, allows the 
user to select the data item to be changed and then requests 
the new value that is to be substituted. The chance function 
will allow the user to change one hill or many hills~ by 


asking the user if he has any more changes. 


ee DELETE 

The delete function allows the user to delete a 
complete set of hill values for the hill number specified 
from the data file. Deletion is accomolished by requesting 
the number of the hill that the user desires to delete, 
locatina that set of hill values and shifting all higher 
hill number values downs overwritting the celeted hill and 
decrementing the number of hills. It 18S recommended that say 
multiple hills are to be deleted, the highest hill number be 


used first to prevent the user from losing trac<x of the 





current hill Numbers since the deletion process~7 also 
logically decrements the hi1]1] number. Multiple deletes = may 
be accomolished since the program will ask the user if he 


desires to delete another hill. 


js, PLOT 
The plot function uses the ~ parametric TADUE Gait, 
which 1s located on the file specified by the user, and 
Generates contour lines of the user specified contour 
interval. The program orompts the user for the minimum and 
maximum x locations, the minimum and maximum y locations, 
the contour interval desired and the minimum elevation in 


the area to be displayed. 


G. MISCELLANEOUS 

The first miscellaneous routine to be discussed 15 
the "“writefile”™ routine. This routine restores/writes the 
hill data from memory to a secondary storage (disk) file for 
SuDsSequent use by the user. The number of hills is written 
mmmete followed by all x locations (xc). fhe file structure 
is completed by writing the entire y locations (yc), hill 
spread values in the x direction (sx), spread values in the 
y direction (Cyc), the rotation values respectively and 
mosing the file. 

The "readfile” routine funetions like the “writefile” 


mumetion but loads the hil) values from the secondary 





storage (disk) file into memory. The filename used is that 
specified by the~- user. at the begqinnina of the termina!) 
session. 

The “printfile”™ routine disolays to the 4014 the hil) 
data located iN memory starting with hill number one and 
continuing to the number of hills that are beinaq used in 
this session. ; 

The “invalidemd”™ routine oroduceS aoprooriate error 
messages to be disolayed on the 4014 for the user. The uSer 
must heed the error message and take appropriate action 
accordingly. 

ives emalist’ routine disolays a!l functian codes to 
the user. It is from this list that the user must select 
the command code correSoonaing to the function desired and 


enter 1t when oOromoted oy the orogram. Al! commands must be 


followed by a carriage return. 


mee oY OTEM USE 

To initiate the program execution after powering on the 
4014 the following procedures must be followed. The first 
steo is to login to the UNIX system with a name of "“parry" 
and a oasSword of “parry”. (Note all entries are lower case 
letters.) The second steo is to enter “terrain" followed by 
@ carriage return and the program will oegin execution 
orompting the user aS needed to steo the user through the 


required orocedures. 





APPENDIX B 


AMMO .CHECK 
NUMBER BYTES OBJECT CODE ;: 496 


PARAMETERS : 
3 rnd 


LOCAL VARIABLES ; p : 
S) answer - 
rnd 


GLOBAL VARIABLES : 


apetow awi.eor.ms! 3 
aweeoreadm Cal 

Bc he.draq 
won.etype 


meametLeED BY °: 
priority.and.round.select 
mee.tactics we.emiss 


COMPLEXITY : Constant storage requirement and execution 
time, 


REMARKS : This routine returns the value of answer to the 
calling routine. 





PARAMETERS 


ARTY.IMPACT 


NUMBER BYTES OBJECT CODE : 1312 


Waebtry 
Vdiet0O 


LOCAL VARIABLES :; 


ans 

’ 

Tahoe 
Ta.m1ss)on 
kk 

m 

time 
time.e 
time.4 
time.6 
within.tolerance 
yy 


GLOBAL VARIABLES : 


caliber 

del.l 
error.code 
Gt.'inhal.t> 
missetolerance 
msnetime 
noemissions.fired 
num.adj.rounds 
rate.of.fire 
rdeceerror 
theta 

volley 
which.volley 
~,curd 

Yecur | 
VMerutures. 1oc 


1ad.40 
1d. fdc 
volleys.to.fire 
within.etolerance 


{eet cdc 
id.mission 


estimate.of.time 
Van5cry 
14.00 

j 

‘| 

rg 
time. i 
time. 3 
time.5 
time. / 
x x 


debug 

del.2 
gsrs.code 
PSS ee pel 
msnename 
my.eradio 

Nowe firing 
Humecdpicm. | eft 
PFGsl.eerror 
Star ir ing 
time. Vv 
volleys.to.fire 
Ye uit | 
Ceruture. oc 
yecur4 


1asbtry 
msn.ename 
num.adj rounds 
time.v 





ARTY.IMPACT (Ccont) 


meaelS ¢ 
arctan. f 
assessment 
error 
position.update 
Orint | 


BemeDULES : 
busy.eradio.net 
Gumse fi ring 


BEMEDULED BY : 
Sums. fi fing 


mee tecAYTY $; Execution is 


constant storage. 


PARAMETERS : 
a 


LOCAL VARIABLES : 
a 


GLOBAL VARIABLES : 
faetime.deltas 


meLLS 3: P 
Normal.f 
wich) t Of mest 


meelLeD BY : 
arty.impact 


cCommo.eattemot 
fdc.processing 


BOMeLEXITY : 


linear on volleys.to.fire but 
ARTY .TIME 
NOMBER OF BYTES OBJECT CQDE : 416 
del.time ; 
rne stream 
tracer 
checkingeguns.availability 
emna.of.mission 
update.cluster 
Constant execution time and storaaqe. 
value of del.time to the calling 


REMARKS : Returns the 


routine. 


arty.time 
dist 
newelocation 
orint 

tracer 


end.of.mission 
open.radio.net 


Py 


ee 





PARAMETERS 


NUMBER BYTES OBJECT CODE ;: 


Vow tT y 
YoO.70 


LOCAL VARTABLES : 


Count 
difference 
id.btry 
ladeto 

j 

] 

ok 

Sigey 
x.eerror 
xdi f 
yYechange 
yenormal.error 
ynew 


GLOBAL VARIABLES : 


alive.dead 
amt.of.ehits 
debug 
displacement 
ae. 

fowl J 

Geet imc. C'S 
kki 1] 

lethal -radius.array 
Mea * 

mk i] | 
numedpicmeleft 
numehe.left 
p.epunch 
rnestream 
time.v 

Kee cur fen Cc 
X.mpo} 
yefuture.loc 
zecurrent 


ASSESSMENT 


eee 


4528 


1a. 1 dc 
1d.m1issi0Nn 


debug.count 
1 

ie a aele 
1d.mission 
“Ne 

m 

$1G. x 

x echange 
xenormal.error 
xN@w 
yeerror 
ViGiot 


ammunition.tyoe 
caliber 

defnum 

deradius 
fired.at 

foe 

Nitestate 
largest .num.wpons 
level.of.camage 
mfkill 

msn.ename 
NUMeQUNS 
memes nt t 
rd.offset 

theta 

wonetype 
Menucure. | oc 
Y.~CUrrene 

Yempoi 





ASSESSMENT (cont) 


MeL tTeES 3 
ammunition.type caliber 
defnum difference 
10 fired.at 
fa) | } guntube 
hit.State j 
kk i) ] med 
mitk it) mk il] 
name ncase 
num.ehit spd 
time.v  *eCurrent 
yecurrent zecurrent 


MesoeRVES : 
rd.offset 


SEEEASES : 


rd.offset 

eects : 
abs.f Sat ri1et 
dist Loe 
New.coordinate.system normal.f 
parameters Site iota t 
Siar t | 


meee eED BY : 
arty.imoact 


COMPLEXITY : Execution dependent on num.eguns and tank mn 
red.alive. Storaqe dependent on largest.num.wpons. 


IMPROVEMENTS : Reverse subscripts on rd.offset. 


bes 





ATRIT 


NUMBER BYTES OBJECT CODE : 2256 


PARAMETERS : 
efkil emkil | 
kKaykil | Shine 
Gat .t whocalled 


LOCAL VARIABLES 3; 


efkill emkil] 
fnow kaykil 
mMNOw Dk 

sh .t EQt.t 


whocal led 


GLOBAL VARIABLES 3: 


alive.dead 


damage.num 


re, ales (@) 
mftkil] mine.det 
mk31] on 
WRITES : 
efkil] emkill 
eae | fx 3 |) | 
kaykil | md 
mfkil] mkil] 
Ok 
maLLS 3: 
uniform. f 
CALLED BY : F 
assessment geom 


mrl.e.imoact 


Som .a.m ine 


red.arty.fires 


BERMEDULES : 
final.death 


COMPLEXITY : Constant 
requirements. 


execution time and 


124 


storaqge 





ATTRITION. CHECK 


UNEMIGBER BYTES OBJECT CODE : 


GLOBAL VARIABLES 3: 
Dapct.att 
n.olue.alive 
reecount 
renum.ealive 


maeLS ° 
imait « f 


BEMEDULES 3 
attrition.check 


SCHEDULED BY : 
attrition.check 


COMPLEXITY : Constant 
requirements. 


execution 


496 


delta.t 
nered.alive 
FebCt.at t 


Stoo. sin) at 1on 


main 


time and 


BAS ea eeaD 


NUMBER 


PARAMETERS : 
a 


LOCAL VARIABLES 3: 
a 


GLOBAL VARIABLES : 
ao.tow 
e. 1 
capds 
casene 
he.draq 
m 1 
m3 
oie) co [alae 


meal eEOD BY : 
o}].create 


COMPLEXITY : Constant storaae and 


ie 


SvteS OBJECT, CODE ; 


2088 


awl.or.mst 3 
Cae 

caseao 
cheat 

nto 

me 

name 
won.tyoe 


red.create 


execution time. 


storage 





Be CREATE 


NUMBER BYTES OBJECT CODE 


LOCAL VARIABLES :; 


1 


GLOBAL VARIABLES : 


BEADS ° 


meEATES ; 


mreeS : 


RESERVES 


RELEASES 


meeeS 3 


BACLED BY 


BeMeLEXITY 


aoetoaw 
benum.ealive 
cocdr 
defnum . 
guntube 
mvestate 
Op.FNaG 
pi-hat 
oltidr 
oreo! t 
recon 

sec 
veh.typoe 
xecurrent 
zecurrent 


oka) 

Gocar 
name 
oltidr 
sec 
wonetype 
yecurrent 


“ 


tank 


in dblue.alive 
Wn olt.unit 


tank 
tank 


list 


bl.create 


basic.load 
hider 


main 


: Storage and execution deoend 


bn 
EG 
color 


direofemvme 


Jist 
name 
Sec 

og ag 
pointer 
rc .ecount 
Prrepoigt 
target 
won.typoe 
yecurrenet 
2h 


co 


dir.of.emvmt 


fenlie 
ori.edir 
veh.tyoe 
x¥eCurrent 


tank 
tank 


elev 


2824 


17 Como .unITt 
In tanks 


on num.ealive. 





BMPS TACTICS 


SvuUveeeeortes OBJEC) CODE +; 264 


PARAMETERS : 
3 b 


LOCAL VARIABLES : 


3 answer 
b 

GLOBAL VARIABLES : 
co — COMO sum) t 
foe tank 


maeLeD BY : 
target.select 


COMPLEXITY : Constant storage but execution time is linearly 
dependent on the number of tanks in como.unit 


REMARKS : This routine returns the value of answer to the 
calling routine. 


BUG. CHECK 
NUMBER BYTES OBJECT CODE 3; i024 
PARAMETERS : 
3 b 


LOCAL VARIABLES : 


a b 
bc 


GLOBAL VARIABLES : 


co compoeunit 
defnum me 
mv.estate Sesame: t 
range tank 
t.sod won.tyoe 


PALLS ; 
‘ dr.emount 


BaeLleE BY : 
Impact 


SemeDULES ;: 
adf.change 


COMPLEXITY : Constant storage but execution in linearly 
dependent on tanks in comp-.unit 


lees. 





BUSY .RADIO.NET 
NUMBER BYTES OBJECT CODE =: 240 


PARAMETERS 3: 
id.radio 


LOCAL VARIABLES : 
id.radio 


GLOBAL VARIABLES : 
state; 


Peel S 3 A 
Brace tr 


Meme DULED BY : 
artyeimpact guns.efiring 


COMPLEXITY : Constant execution time and 
requirements. 


re 3 


storage 





CARDIO 
-NUMBER BYTES OBJECT CODE : 1280 
PARAMETERS : 
a b 


pct.vis r 
x 


LOCAL VARIABLES : 


a angle 

area at 

b - ot 

dd denom 
det.time lambda 

mt Si. sub. Kk 
eert.vis per.full.expo 
r rr 

t.c.factor tgt.element 


GLOBAL VARIABLES : 


bearea blue 
cbar color 
dir.ofemvmt Dic 
pi.hat pry.dir 
r.earea red 
sod x.-current 
yecurrent 21 

ects 3 
abs. f arctan. f 
log.a.ft sin. f 


MacLeED BY : : 
steop.time 


COMPLEXITY : Constant execution time and storage 
requirements. 


IMPROVEMENTS : All local variables need to be defined. 


REMARKS : Returns the value of det.time to the calling 
routine. 


Lae, 





CHARGE 
iGgegex BYTES OBJECT CODE : 2152 


PARAMETERS 3: 
Cc 


LOCAL VARIABLES : 


avgxc avgx5 
avgx6 avgx/7 
avgyc avay5 
avgyo avgy/ 
Cc Ge 
ke b 
m aCe 
x5 x6 
x 7 yc 
yS y6 
y7 

GLOBAL VARIABLES : 
bn red.alive 
tank xC 
xe current ye 


yecurrent 


BeLlLS ¢ 
get.up 


SemeEDULES ; 
charge 


SemeDULED BY : 
charge leave.check 


COMPLEXITY : Execution time is linear on number tanks in 
red.alive.e Storage requirements are constant. 


boo 





CHECKING.GUNS. AVAILABILITY 


-NOMBER BYTES OBJECT CODE ; 


PARAMETERS 3: 
ieeotry 
id. fO 


LOCAL VARIABLES : 
1debtry 
Were tO 
time 


GLOBAL VARIABLES : 
bitery 
fire.dir.center 
msn.ename 
num.adj.rounds 
qQueue.size 


1824 


iat ac 
id.mission 


Ve 4 yrele 
1d.emission 


4 


debug 

label 
msn.time 
NumemiSsions 
Queve.time 


state statel 

St. 1 f 1a timeev 
WRITES ¢ 

na.ot ry id.fdc 

ra .fo msnename 

state time.v 
mrLeS ; 

1demisSion in howitzer.queue 
mae S 3: 


arty.time 


BiemeOULES 3: : 
Sunset vr 1ag 


SemenULED BY : 
fdc.processing 


COMPLEXITY : Constant 
requirements. 


ey 


execution 


tracer 


time and 


Storage 





-NUMBER 


PARAMETERS : 
a 


LOCAL VARIABLES : 
a 
Zyx 


GLOBAL VARIABLES : 
blue 
css 
mvestate 
rec 


Paks : 
set.sector 


BaeLl—ED BY : 
step.time 


COMPLEXITY : Constant 
requirements. 


IMPROVEMENTS 3 
Source code. 


Needs to be 


CHG.SEC.SEARCH 


Byres OBJECT CODE ; 


xyZ 


- CoOulor 
Gur. otf .mymt 
ori.dir 


ini ho tom of 


execution time 


rewritten to Save 


ere 


1304 


and 


4a 


storage 


lines 


o f 





nitii@er BYTES OBJECT CODE : 


PARAMETERS : 
TclaitO 
,ad.raqdio 


LOCAL VARIABLES : 
10d.fo 
id.eradio 


GLOBAL VARIABLES : 
error.code 
state 3 
wait.etime 


PILES 


1de-mission 


maclS : 
artyetime 


SCHEDULES 3; 


COMMO.ATTEMPT 


1096 


i1demissiton 


1d-mission 
time 


rdle 


IN msnNn.queue 


commo.attempet 
open.radio.net 


SemeDULED 8Y ; 


commo.attempt 


BOMPLEXITY : 


Constant 


execut 


requirements. 


= 


S35 


time.v 


tracer 


fdc.processing 


and 


ION time 


storage 





PARAMETERS : 
3 


LOCAL VARIABLES : 
a 
baim 
“ 


GLOBAL VARIABLES 3: 
bwd.look 
foe 
oo.erng 
out 


meee Ss §$ 
dist 
sight 


BeeLeD BY 3 


COMMO.PASS.TGT 


NUMBER BYTES OBJECT CODE ; 488 


aim 
lose 


Critical.value 
fwd.look 
petevis 


lec 


Ce7eswtactics 


COMPLEXITY : Constant execution time and 
requirements. 


REMARKS : This routine returns the value of aim 
calling routine. 


134 


storage 


\e1o, 


the 





PARAMETERS 


COMPUTE 


“NUMBER BYTES OBJECT CODE : 3528 


° 
e 


teOocvis 
Sh.t 


LOCAL VARIABLES : 


addef] 
deflbias 
elbias 
f.pcvis 
10 

lk 

Oe.Vvis 
sh.t 

ve} 


GLOBAL VARIABLES : 


WRITES : 


CALLS 3; 


BeeLeD BY 


meer ceXITTY 


aceht 
accmbd 
addon 

ht .mov 
sod 
xecurrent 


oh ucsig 
min. f 
Eeunc . tf 


Impact 


: Constant 
requirements. 


OCeVIS 
Lot. 


adde| 
deflsig 


accke 
accms] 
om.emov 
SEGIo 
wonetype 
yecurrent 


geom 
suocal 


execution time and 


storage 





NUMBER BYTES OBJECT CODE ;: 


PARAMETERS 3; 


3 


LOCAL VARIABLES : 


a 


GLOBAL VARIABLES : 


meets : 


CALLED BY 


SOMPLEXITY 


c¢.bar 
defnum 
qd.num 
micro 
p.hat 
plow.cond 
$pa 
t.spd 
Xo 
am oe 6 
Zect 
zh 


pop.eaemine 


loc 


: Constant 
requirements. 


- 


CONVERT .BACK - 


712 


pi.eint 


cbar 


dir.ofemvmt 


execution 
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m.det 
mine.det 
rol | ites 

DV 
time.yv 
Vems 
xecurrent 
yeCcurrent 
zecurrent 


time and 


Storage 


DECREMENT.AMMO 


NUMBER BYTES OBJECT CODE : 768 


PARAMETERS 3; 
3 


LOCAL VARIABLES :; 
a 


GLOBAL VARIABLES : 
ap.tow 
awe.oreadm 
ogee a 
he.drag 
won.type 


meeeeED BY ; 
fire 


COMPLEXITY : Constant 


rnd 


rnd 


awleor.ems| 3 
ces | 
ert 
eae 


storage and execution time. 


leer 





PARAMETERS 


DERENG 


NUMGCReeY hes CEMECY CODE = 


3 


LOCAL VARIABLES : 


3 


GLOBAL VARIABLES : 


BALLS 3 


SeeceD BY 


BOMPLEXITY 


alive.dead 
defnum 
mveState 

3) \) Axes 

sod 

time.v 
won.etype 


dismount.dragon 
set.sector 


loc 


: Constant Storage and 


ie 


688 


apetOw 
Ufa 

name 
eye i) coll (pe 
target 
t.spd 


hider 


execution time. 





DETECT 
NUMBER BYTES OBJECT CODE : 792 


PARAMETERS °: 
a b 


LOCAL VARIABLES 3 
3 b 
whocalled 


GLOBAL VARIABLES :; 


alive.dead - bwd.look 

critical.value ‘defnum 

fa fic 

rae fwd.look 

line.of.sight.exists PCct.vis 
meaelS °;$ 

list.update loc 

proximity.detect sight 

tracer 


SemeDULED BY : 
impact step.time 


COMPLEXITY : Constant Storage and execution time. 


IMPROVEMENTS : Delete the variable whocalled = declared 
unused. 


se 


but 





PARAMETERS 


““NGMBER BYTES OBJECT CODE : 


a 


LOCAL VARIABLES 3 


3 


GLOBAL VARIABLES :; 


BALLS ; 


SCHEDULED 


BOoMrPLEXITyY 


PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


macts : 


BeLLED BY 


SOMPLEXITY 


alive.dead 
defnum 


hider 
By 


bugecheck 
leave.check 


DF .CHG 


496 


dremount 
loc 


: Constant storage and execution time. 


NUMBER 


3 


PBLES 3 
rs 


PASE S ¢ 
defnum 

me 

name 

olt 
Ori.dair 
target 
xecurrent 


hider 
set.sector 


defend 


$ Storage reauirements are constant but execution 
linearly dependent on the number of tanks 


time is 
ferveuonl Gretel iti. 


DISMOUNT .DRAGON 


Grreo Cbweetl CODE =: 744 


he.draaon 
mv.state 
Sic 
Slee? t 
tank 
won.etype 
yecurrent 


loc 
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DIST 
BNUMSER BYtES OBJECT CODE =: 144 


PARAMETERS : 


x1 x2 
y | ye 
LOCAL VARIABLES : 
distance x 1 
x2 yl 
ye 
PALLS : : 
SG rit. f 


meeceD BY ; 


artyeimpact assessment 
commo.attempt compute 

error fde.proeeéssing 
fire qumsS. fi rerng 
impact new.location 


COMPLEXITY : Constant storage and execution time. 


REMARKS : Returns the value of distance to the callina 
routine. 
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PARAMETERS 


DOING.CLUSTERS 


"NUMBER BYTES OBJECT CODE : 5048 


T4a<fo 
pri.evalue 


LOCAL VARTABLES : 


— w- —<- TF QQ 


n 
prt.value 
tank 

x 


GLOBAL VARIABLES : 


WRITES ¢: 


eacls : 


eemeteD BY 


COMPLEXITY 


REMARKS 3: 


alive.dead 
box.tolerance 
Cenumber.arfray 
dir.ofemvmt 
fo.min.range 
name 

sod 

taraqet 
yeCurrent 


clusters 
earl, 


aos. f 
cos. f 
loc 


update.cluster 


Name.priority 


angle 

dir 

13.40 
5 

m 
name.oriority 
S 
total.cliusters 


Y 


b.eorg.alive 
clusters 
debua 
fo.max.range 
list 


old.ciluster.enumber 


stated 
XxeCurrent 


aretan.. f 
dim. f 
S.\ fre f 


: Storage 1s constant but execution is 
on the product of the size of the target 
the total number of clusters. 


Returns the values of name.oriority and 


to the calling routine. 


deoendent 


ori.value 





“NUMBER BYTES OBJECT CODE 


PARAMETERS ; 


= | 


LOCAL VARIABLES :; 


3 


GLOBAL VARIABLES : 


BAELED B8Y 


SCHEDULES 


SOMPLEXITY 


ao.etow 
fip 

me 

name 
pit.unit 
target 
t.sod 
xecurrent 


bugecheck 


ef .chq 


: Execution time 
mn 


tanks 


constant. 


Sit cunm ¢t 


DR. 


MOUNT 


J. 


defnum 


- he.drag 


Increases 


143 


mvestate 
ey || ic 

tank 
time.v 
won.typoe 
yecurrent 


leave.check 


with 


linear 
wonetyoe = 6 
he.drag(tank) gt 0 and fir(tank) ne l. 


ih 


with 


Storage 


number 


and 
1s 





END.OF MISSION 
NUMBER BYTES OBJECT CODE : 2704 
PARAMETERS : 
id.btry id.fde 


id.fo id.mission 


LOCAL VARIABLES : 


estimate.of.time 1 Gato tts ¥ 
lich tf cc o}5 Fe. 
1d.mission time 
time 


a 


GLOBAL VARIABLES 3: 


amt.active.msns amt.msns.fired 
otry debug 
fist 
holding.emsns howitzer.queue 
labe|] mission 
msnename 
msn.time my.radio 
new.location numead} rounds 
queue.size queuve.time 
statel Sterne 
time.v which.volley 
Meet eES : 
fist 1o.o ery 
var t dc so Fran ate, 
msn.name time.v 
mreeS 3: 
id.-mission 1n msn.queue 
REMOVES : 
idemission from howitzer.aueue and holding.msns 
CALLS 3° 


arty.time tracer 


SCHEDULES 3 
fo.nmot. ous y Gucs.t hing 
onen.radio.net 


SEMEDULED BY : 
artyeimoact error 


COMPLEXITY : Constant execution and storage requirements. 


144 





PARAMETERS 


LOCAL VARI 


NUMBER BYTES OBJECT CODE : 944 


ans 
id.fdce 


ABISES is 

ans 

Tio lA ete Ke 
idemission 
S19.yY 

xdif 
xenormal.error 
yeimpact point 


GLOBAL VARIABLES :; 


BALLS 3: 


CALLED BY 


SEMEDULES 


more LEXITY 


ammunition.tyoe 
error.code 
rnestream 

xe future.loc 


dist 
normal. f 
position.update 


arty.imoact 


end.of.mission 


: Constant execution and 


ERROR 


145 


id.otry 
10.f6o 


1d.btry 
1d. 10 
S10. x 


-tank 


Xeimpact.point 
ydi f 


-yenormal.error 


caliber 
Giweaitneals. | OC 
theta 

Var UCU Re oC 


new.coordinate.system 
Darameters 
tracer 


storage requirements. 





FAL1.MAIN 
NUMBER BYTES OBJECT CODE : 4936 
LOCAL VARIABLES : 
i ) 
kK 


mM 


GLOBAL VARIABLES 3: 


amt.ammo.types amt.bdlue.batterys 
amt.calivers amt.fa.etime.deltas 
amt.ffe.volleys — amtemr) 
amt.red.ovatterys varty.pk.table 
benum.alive b.eorg.ealive 
box.tolerance Couvorl 

cutoff.time debug 

displacement d.eradius 

foemax.range foemin.erange 
fo.evehicle fwd.obs.msn.tolerance 


laraest.num.wons 
maxenumber.of.missions.per.fo 


max.eranae miss.etolerance 
nebattery Awtae 

aie 1 O noerange.bands 
Neradio num.doicm.left 
numehe.left Num.e guns 
p.punch range.bvands 
eate.of.fire red.l.constant 
renum.alive rn.estream 
r.org.alive salvos 
sigma.dpoicm tet.acq.error 
travel.time.array tretime 

x.cuPpl xecure 

¥ecurt Vo acume 
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READS 3: 


CREATES ; 


MEeSERVES : 


Meee ASES : 


maALLS 3: 


CALLED BY 


COMPLEXITY 


IMPROVEMENTS 3: 


FA.1.MAIN (cont) 


amt.ammo.tyoes 
amt.calibers 
amt.ffe.volleys 
amt.red.bdatterys 
box.tolerance 
cutoff.time 

disolacement 
fo.max.range 

fo.evehicle 
largest.num.wons an 


amt.dlue.batterys 
amt.faetime.deltas 
amt.mr| 

arty.pk.etable 

colorl 

debug 

d.radius 

fo.emin.range 
fwd.obs.emsn.tolerance 


max.enumber.of.missions.per.fo 


max.range 
neodattery 

ne fo 

Nn.eradio 
numehe.left 
p.epunch 
rate.of.fire 
sigma.dpicm 
travel.time.array 
xwcur | 


battery 
fo 


array.detect 

clusters 

disolacement 
fa.etime.deltas 
lethal.radius 
red.planned.fires 
time.last.cluster.update 
travel.time.array 


preplanned 


oreplanned 


main 


Se yaear fon m.efdc, 
amt.calibers, 


NneDdattery, 
amt.blue.batterys * 


miss.etolerance 
Metoc 
noerange.bands 
num.dpicm.left 
num.eQGuns 
range.bands 
rnestream 
tgqt.acq.error 
tr.etime 

Y.cur. 


{Ge 
radio 


arty.ok.tabdle 
Cenumber.arfray 


fo.evehcle 
range.bands 
s$igma.dpicm 
Cotc.acad.error 


amt.ammo.types * 
NMuUMeQunsSss 


amt.caliders * no.erange.bands 
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Reads num.dpicm.left then sets to 0. 





FA.2.MAIN 


“NUMBER BYTES OBJECT CODE : 3472 


LOCAL VARIABLES 3 


1 
ik 


GLOBAL VARIABLES : 


amt.ammo.typres 
amt.calibers 
amt.ffe.evolleys 
amt.red.ebatterys 
beorg.ealive 
cutoff.time 
deradius 
foemax.erange 
foevehicle 
largest .num.ewons 


amt.blue.batterys 
amtefaetime.deltas 
amtemr | 


artyepk.etable 


box.etolerance 

debug 

fa 

foemin.ranage 
fwd.eobsemsn.tolerance 
lethal.radius 


maxenumber.of.missions.per.fo 


missetolerance 
meer ac 
noerange.bands 
netanks 
pointing.to 
rnestream 

fe iplelonh (ais 


amt.e~ammo.tyoes 
amt.calibers 
amt.ffe.volleys 
amt.red.bdatterys 
box.tolerance 

deodug 

foemax.range 
fwd.obs.emsn.tolerance 


n.edDattery 
Nieto 
Nneradio 

io) Sle 
p.epunch 
r.orgealive 
type 


amt .blue.batterys 
amt.efa-etime.deltas 
amt emr} 
beorg.alive 
cutoff.time 
d.radius 
fo.min.range 
largest -numewons 


maxenumber.of.missions.per.fo 


missetolerance 
Nerac 
noerange.ebdbands 
netanks 
r.orgealive 


nedattery 
alr te 
neradio 
p.epunch 
rnestream 





FA.L2.MAIN (cont) 


meek S : 


meelL—ED BY : 


MemeDULES °: 
red.earty-fires update.cluster 


COMPLEXITY : Linear on n. for amtecalibers * amt.ammo.tyoes * 
9, amt.ered.batterys - amt.mr| 


IMPROVEMENTS : Combine major looos. 
FA.TGT.ERROR 
NUMBER BYTES OBJECT CODE : 416 


PARAMETERS : 
a loc.error 


LOCAL VARIABLES : 
Fe) loc.eerror 


GLOBAL VARIABLES °: 
rnoestream tgt.acq.error 


mactlsS : 
tracer uniform. f 


MecLLED BY : 
new.location 


COMPLEXITY : Constant execution and storage requirements. 


REMARKS : This routine returns the value of loc.error to the 
calling routine. 
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PARAMETERS 


FOC .PROCESSING. 


NUMBER BYTES OBJECT CODE : 3424 


Vol ee. 


LOCAL VARIABLES : 


di ff 
id.btry 
idemission 
k 

m 

time 
volleys 

yy 


GLOBAL VARIABLES : 


WRITES 


BILES 


CALLS 


ammunition.type 
amt.ffe.volleys 
debug 
error.code 
gtsfinal arog 
mission 
msn.ename 
msn.time 
neholding.msns 
process 

start 

Status 

time.v 
volleys.to.fire 
xecurd 

yecurl 
yefuture.loc 


1 

msnename 
qQueue.size 
time.ev 


id.emission 


1 
1d .ts 
j 
1 


men? 
type.ammo 


xX xX 


amt.active.msns 

busy 

doicm 
fwd.obs.msn.tolerance 
gteinitial.rg 
my.radio 


iat ce 
Numemissions 
qQueue.size 
statel 

theta 


ecu | 
xe future.loc 
yecur4d 


Tae f oO 
NumMemiSsions 
statel 


1demission in holding.msns and msn.queuvue 


arctan. f 
dist 


arty.time 
tracer 





FDOC.PROCESSING (cont) 


BCHREDULES : 
checkingegunsS.availibility 
foenot ebusy 


SCHEDULED BY : 
commo.attemot 


COMPLEXITY : Execution time is linear with n.fde and storage 
is constant. 


IMPROVEMENTS : Combine ali "for™ loops into one. 


et 





PARAMETERS 


FINAL .DEATH 


NUMBER BYTES OBJECT CODE : 


3 


LOCAL VARIABLES : 


a 


GLOBAL VARIABLES 3: 


WRITES : 


CALLS ;: 


SCHEDULED 


COMPLEXITY 


alive.dead 


arene. 

fkil] 
hit.estate 
kki 7] 
mfkil] 
name 
numehit 
time.v 
xXxeCcCurrenet 
zecurrent 


defnum 
frred.at 
guntube 
Ke Art 

med 

mki1] 
nease 

soa 
won.type 
y.ecurrent 


tally.hit.state 


By < 
atrit 


4 Constant 
requirements. 


S 


defnum 
fired.at 
guntube 
Keen tt 

med 

mkill 
nease 

sod 
won.etype 
yecurrent 


f 20 

ea EL 
hit.state 
kki ll 
mfki1] 
name 
Numehit 
time.v 

xe current 
zecurrent 


execution time 


1424 


and 


storage 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


meets ; 


SCHEDULES 


SCHEDULED 


COMPLEXITY 


FIRE 


WOMBER BYTES OBJECT CODE : e232 


a 


ABLES $ 

a 

lose 

Stoo «Count 


PABLES : 
alive.dead 
bwd.look 
color 
defnum 
fip 

fwd. look 
mzi.vel 
Set. vis 
projo 
sched 
eat. Sc | 
won.etype 
y.current 


decrement.ammo 
hider 

set .muzzle.vel 
stop.toefire 


e 
[7 
e 


impact 


By 3 
Rreetacti cs 
weemiss 


: Constant 


requirements. 


SS 


1d 


id 
r 


‘blue 


check.time 
ECTENCalsvalue 
foe 

fkill 
mvestate 

oo .erng 
pointer 
range 
second.shot 
time.v 
xecurrent 


dist 
loc 
sight 
tracer 


target.select 


taraqet.select 


execution time and 


storage 





FERST 


NUMBER BYTES OBJECT CODE : 288 


meRAMETERS ; 
a 


LOCAL VARIABLES : 
a 


GLOBAL VARIABLES : 
mu : ranqe 
won.tyoe . 


meelLsS : 
runic. f 


CALLED BY 3 
lay.load 


COMPLEXITY : Constant execution time and 
requirements. 


FO.NOT.BUSY 
NUMBER SY7ES GOBIJEGT CODE :; 408 


PARAMETERS 3: 
Va. fo 


LOCAL VARIABLES : 
Vato 


i) 


GLOBAL VARIABLES : 
amt.eactive.msns idle 
Status 


SemeDULES 3; 
uodate.cluster 


SCHEDULED BY 3: 
end.of.mission fde.processing 


COMPLEXITY : Constant execution time and 
requirements. 
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Storage 


storage 





GEOM 
-NUMBER BYTES OBJECT CODE : 8080 


PARAMETERS ; 


addef | adde | 
deflbias deflsig 
elbias elsig 
f.pcvis peeVvi1s 
r sh.t 
tat. & 

LOCAL VARIABLES : a 
addef | “ addel 
aimdis defdis 
deflbias defilmiss 
deflsig diswk 
efkill efol 
elbias eldis 
elmis elmiss 
elsig emki]] 
emp | f.DeEVIs 
f k Gamma 
1 10 
j jo 
kk Kaykil | 
kayo] kk 
] lenath 
m m lk 
mo mo 
n Se.vis 
r ro 
Ssh. t size 
eiagit.. ¢ turret 
ve] whocalled 
width Xiect 
yet 


GLOBAL VARIABLES :; 


alive.dead damage.num 
dir.eofemvmt Anorm 
jynorm kKkill 
lell lel2 

le31 leél 

le/i le72 

le8l 1e83 
norseed ola 

projo sod 
tardin veh.tyoe 
won.type Yecureent 


yecurrent 


155 





GEOM (cont) 


meclLS 3; 
abs.f arctan. f 
atrit COS «f 
loadn Sim. t 
trunc. f 


meeLED BY : 
compute 


N 


COMPLEXITY 4 Constant execution time and 
requirements. : 


GET SUE 
NUMeeR MBytes OBJECT CODE = 576 


PARAMETERS : 
a b 


LOCAL VARIABLES 3: 
a b 


GLOBAL VARIABLES 


a0etow oka 
defnum mveState 
name red.alive 
tank target 
won.type 

meets : 
loc... 


MmeeLED BY :; 
charge 


BOMPLEXITY : Constant execution time and 
requirements. 
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storage 


storage 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


WRITES : 


macls ;: 


SCHEDULES 


SCHEDULED 


meMeLEXITY 


GUNS.FIRING 


NUMeemMnerteS OSsECT CODE :; 1768 


Vos o Urry 
Vae tO 


ABLES : 
id.btry 
id.fo 


ho a 
type.eammo 


PABLES 3: 
ad).round 
caliber 

Sear imMaise tg 
myeradio 
time.v 
which.evolley 
mecur i 
yecuri 


id-btry 
1a. 10 
time.v 


dist 


arty.imoact 
ooen.radio.enet 


ers 
artyeimoact 


checking.gunsS.availability 
end.of.mission 


: Constant 


requirements. 


id.fdc 
1demission 


14.fdc 
id.mission 
tor 


wonetype 


ammunition.tyoe 


debug 
msnename 
Nowe firing 


travel.time.array 


ecu Cu Meee] OC 
yefuture.loc 


TaoSfde 
mSnename 
which.volley 


tracer 


busyeradio.net 


execution time and 


storage 





NUMBER BYTES OBJECT CODE : 


PARAMETERS : 
r= | 


LOCAL VARIABLES :; 
a 
whocalled 


GLOBAL VARIABLES 3: 
alive.dead 
mveState 


meeLS 3 
hider 


SOMEDULES s: 
hide 


op 
hide 
weehit 


SCHEDULED 


COMPLEXITY : Constant storage 


NUMBER BYTES OBJECT CODE ;: 


PARAMETERS 3: 
3a 


“ 


LOCAL VARIABLES : 
a 
aname 


GLOBAL VARIABLES 
defnum 
name 
zh 


mecls : 
mcov 


MmaeLeED BY 3; 
bl .create 
OP elaie) 
fire 
red.create 
we.hit 


COMPLEXITY : Constant storage 


USB) 


130 


whocalled 


hold 


~ defnum 


reload 


reload 
we.emiss 


and execution time. 
HIDER 


520 


adef 
wtype 


micro 
wonetype 


defend 

dismount.dragon 

hide 
target.select 
weemiss 


and execution time. 
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IFV.TACTICS 
WUmB@ER BYTES OBJECT CODE : 35e 


PARAMETERS : 
a 5 


LOCAL VARIABLES 3; 


3 answer 
b 2 
GLOBAL VARIABLES : 
foe pit 
pit.unit tank 


PeaeLS ;: 
uniform. f 


meeceD BY ; 
target.select 


COMPLEXITY : Execution is linear on tank in oplt.unit and 
storage is constant. 
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PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


WRITES : 


IMPACT 


NUMBER BYTES OBJECT CODE ; 


e 
e 


a 
y 


MELES : 

a = 

dt 

r 

whocal led 
y 


LABGES -: 
alive.dead 
check.time 
critical.value 
dam.arfray 


fwd.look 
Quntube 
eth 1 

Kk ill 
mfkil] 
mmm 

name 
Numehit 
pet.evis 
projo 

spd 

tow. kount 
won.etype 
Vecur ment 


defnum 
fired.at 
gQeamm 
hit.state 
kki ll 
mfkill 
name 
num.hit 
projo 

sod 

ie 

x -ecurrent 
Z2ecurrent 
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id 


answer 
id 
stopcount 
x 


A 


bwd. look 
co 
damage.num 
defnum 
f.d 

£110 

foe 

Qeamm 
hit.state 
killer 
med 

mk tt 
mv.eSstate 
ncease 
Seo.V1Ss 
pointer 
range 
time.v 
ttt 
xecurrent 
zecurrent 


eee, 
fkill 
guntube 
Koni t 
m.d 
miko | 
ncase 
pcb.vis 
range 
time.v 
won.etypoe 
yecurrent 


4488 





IMPACT (cont) 


meLlS 3 
bug.check compute 
dist list.update 
loc sector.check 
sight stop.to.fire 
tally.hit.state tracer 
we.hit we.emiss 


BERMEDULES : 
detect mel.eimpact 
new.fo 


7 


Meme DULED BY : 
fire 


COMPLEXITY : Constant execution time and 
requirements. 


os 


storage 





Diy ae ICS 
NMOMBER@= BYTES OBJECT €ODE =: 352 


PARAMETERS : 
a b 


LOCAL VARIABLES 3: 


a answer 

fe) 2 
GLOBAL VARIABLES 3: 

foe : plt 

Hit.unit tank 


meeLS °: 
uniform. f 


COMPLEXITY : Execution time linear on tanks in olt.unit and 
Storage 1S constant. 


BeLLED BY 3: 
target.select 


REMARKS $s: Returns the value of answer to the callina 


routine. 
PAY .th0AD 


NUMBER BYTES OBJECT CODE =: 2136 


PARAMETERS : 
a x 


LOCAL VARIABLES : 
a time 
x 


GLOBAL VARIABLES : 
projo wen.type 


eaAcls 3: 
first maxef 
normal.f 


BRLEED BY 3 


tié.tactres target.select 
we.emiss 
mOMPLEXITY : Constant execution time and storage 


requirements. 


REMARKS : Returns the value of time to the calling routine. 


hoe 





PARAMETERS : 
3 


LOCAL VARIABLES : 
3 
bb 
cb 
ij 
im 


GLOBAL VARIABLES : 
apetoOw 
bn 
color 
defnum 
hasty 
mvestate 
Olt 
red 
tank 
t.dead 
t.sod 
won.type 


PecELS : 
Ginemount 
trunc.f 


MmeetED BY : 


LEAVE.CHECK 


NOMBER BYTES OBJECT CODE : 9768 


ecomoe.unyt 


ert tim t 
red.alive 
target 
time.v 
upper.lower 


Loc 


taildiyehitestate 


SEeMeDULES ;: 
charge 


at .cng 


COMPLEXITY : Execution time deoends on tanks in comp.unit 
tanks in olt.eunit and storaae 1s constant. 


ay) 





LIST.UPDATE 


NUMBER BYTES OBJECT CODE : 1840 


PARAMETERS : 
3 
lose 


LOCAL VARIABLES 3 
a 
count 
. £ 
size 


GLOBAL VARIABLES : 
alive.dead 
list 


MESERVES 3 


list 
RELEASES : 

list 
BaclS : 

dim. f 


uniform. f 


MeeLED BY : 
detect 
proximity.detect 


SeRMEDULES ; 
target.select 


COMPLEXITY : Execution time and 
elements in Jist. 
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b 
whocalled 


b 
flag 
lose 


~ whocalled 


fa 
temo.tgt 


min. f 


impact 
target.select 


Storage are linear 





PARAMETERS 


NUMBER BYTES OBJECT CODE : 


tank 


LOCAL VARIABLES ; 


tank 


GLOBAL VARIABLES : 


REMOVES 3 


MEEEASES 3: 


BectS 3: 


BACLED BY 


SCHEDULES 


SOMPLEXITY 


alive.dead 
(are) 

defnum 

mki Jl 
mvestate 
olt 

sod 
won.tyoe 


tank from red.aliver comp.unit and olt.unit 


list 


convert.back 
param.set 


assessment 
detect 
doingeclusters 
get.un 
leave.check 
mel.eimpact 
red.arty.fires 
t7e.tactics 


df.cha 


: Constant 
requirements. 


LOC 


1096 


blue 


ee owor 


execution 


'Go 


list 
mered.alive 
name 

red 

target 


defend 


commo.cass.tct 
dismount.draaon 
fire 

Impact 
loc.eupdate 
position.update 
stop.simulation 
target.select 


time and 


storage 





LOC .UPDATE 


' NUMBER BYTES GBJECT CODE : 384 


BOCAL VARIABLES 3 
tank 


GLOBAL VARIABLES : 
alive.dead 


meets : 
loc 


BEMEDULES : 
loc.uodate 


BeMEDULED BY 3: 
loc.update 


COMPLEXITY : Constant 
requirements. 


delta.t 


red.create 


execution time and 
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storage 





MAIN 


NUMBER BYTES OBJECT CODE : 35928 


LOCAL VARIABLES :; 


cnum 
j 


GLOBAL VARIABLES : 


READS 


area 
bc.ecount 
Depet.att 
case 
cdtime 
constant 
d.num 
def.time 
asl 
guntube 
1.dead 
jnorm 
lines.v 
mmm 

ncease 

ANN 
n.platoon.leader 
pca.vis 
peo. V1S 
platoon.leader 
De V 
r.earea 
renum.ealive 
seed.v 
s2.time 
target 
temo.tgt 
tte 

Vvems 

XeCct 

Yect 

Zac t 


benum.alive 
cnum 

dsl 

gQuntube 
Nncase 
renum.ealive 
seed.v 
x.Stop 


onum 


bearea 
benum.alive 
bttime 


gee ol- ip 
Fa 


comoany.commander 
critical.evalue 
dam.array 
deita.t 

dse 

hasty 

itedead 

lin 

medet 

mu 

Nne-company commander 
norseed 
pca.eunc 
pco.UuUnC 

pehat 

ong lee cs 

Qa 

reecount 
reOct.att 
sl.time 

steps 

t.dead 

totsci 
upper.lower 
Wek eC 

xeStOO 

yestoo 

Pala 


Deere at t 
delta.t 
dse 

mu 

onum 


Dy 


eOct.att 


upoer.lower 
V~eStoo 
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WRITES 3: 


mREATES 


RESERVES 


BeLEASES 


BALLS : 


MAIN (cont) 


Bnpet.att guntube 


norseed fooCce. at t 
upper.lower xectom 
yestoo 


every platoon.Jleader every company.commander 


e 
@ 


bobpoint ac. bar 
dam.array ‘denum 

dsl dse 
1.dead it.dead 
m.edet mu 
pcaeunc oCaevis 
pcb.unc pcb.evis 
Sehat pc 

DPeV qaqa 
rereooint target 
t.deaad temo.tat 
tqtsc] Vems 

xe COU yect 

Zac t zh 
faeil.main faweomatn 
resl rese 

res3 res4 

res5S 

bl.create CO Si. t 
faei.main feeecoumal a 
wma trd loadn 
resl rese 

res3 res4 

res5 set.sector 


vals.for.case 


SCHEDULES ; 


COMPLEXITY : Execution is dcependent on the number of tanks. 
Storage 1S denendent on the number of platoon 


REMARKS 


attritton.check new.forces 
steo.time stoo.simulation 
stopesimulation 


leaders, the number of company commanders and 


number of elements in renum.ealive and oenum.alive. 


; Main routine starts the simulation. 
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PARAMETERS 


MRC MP AGT 


NUMBER BYTES OBJECT CODE 


Moral ele 


LOCAL VARIABLES : 


id.ebtry 
noemens.fired 
red.ececonstant 
x 

veo 10C 


GLOBAL VARIABLES : 


BeITES $ 


eels : 


SCHEDULED 


alive.dead 
caliber 
defnum 
Treedeaat 
foe 
hit.estate 

ke ery tC 

med 

mkil] 

nease 
numehe.left 
red.l.constant 
tank 
won.etype 
yecurrent 


Caliber 
ao ie 
fkil) 
Niet .s ta tie 
ey. | 
mfkill 
name 
num.ehit 
time.v 
xecurrent 
zecurrent 


aos. f 
loc 
uniform.f 


By, «2 
impact 


yeloc 


id.reda.btry 


ok 
tyoe.ammo 
xeloc 


2508 


arty.pk.table 


debug 

f sie) 
feild] 
qauntube 


kk ill 
me 1/1 | 
name 


noemsns.fired 


numehit 
sod 
time.v 
Mac wuenrenm t 
zecurrent 


defnum 
fired.at 
gQuntube 
ent 

un! 

mkil] 
ncase 

sod 
tyope.ammo 
yecurrent 


atrit 
tracer 


roo 





MRL.IMPACT (cont) 


COMPLEXITY : Execut.ion time is linear on tanks in blue.alive 


and storage 1s constant. 


REMARKS : Local variable no.mens.fired should 


noemsns.fired. 
NEW.COORDINATE.SYSTEM 


NUMBER BYTES OBJECT CODE : 88 
PARAMETERS 3 
angle _. xold 


yold 7 


LOCAL VARIABLES ; 


angle xnNew 
xold ynew 
yold 

eecls ; 
cos.f Slime 
ied Ge f 


BeLLED BY : 
assessment error 


BomeLeXi;ry : Constant execution time and 
requirements. 


REMARKS : Yielding xnew and ynew 
NEwW.FO 
NUMBER BYTES OBJECT CODE : 456 


PARAMETERS : 
3 


LOCAL VARIABLES ; 


blue.alive co 
fa Oeste or 
tank type 


SemeNULED BY : 
Impact 


COMPLEXITY : Execution time is linear on tank in 


be 


storage 


blue.alive 


with co(tank) = cola), until tank = pltldr(tank). 


Storage requirements are constant. 
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NEW.FORCES 


Ditweer BYTES OBJECT CODE =: 128 


PARAMETERS : 
start 


LOCAL VARIABLES :; 
Start 


GLOBAL VARIABLES : 
name 


MELEASES : 
bobpoint 
rerpoint 


SAclS ; 
red.create 


SemeDULED BY 3: 
main 


COMPLEXITY : Constant 
requirements. 


stop 


stop 


ve 


red.create 


execution time and 


Storage 





NEW.LOCATION | 


NUMBER BYTES OBJECT CODE : 1384 


PARAMETERS 3; 


a 
1demission 


LOCAL VARIABLES 3; 


a 

distance 
err.ed 
err.4 
err.6 
err.8 
Taste 
1d.mission 
ae 


ee 


GLOBAL VARIABLES 3: 


Seeks : 


meeceD BY 


SOMPLEXITY 


dir.aoparent 
error.code 
sod.aoparent 
x.curd 
yecur4 


arctan. f 

dist 
position.update 
tracer 


a ad 
es 


arty.e.imopact 


: Constant 
requirements. 


del.time 


del.time 
err. | 
err. 3 
err. 
err./7 
id.obtry 
Tecate 
tank 

Xee 


XX 


direction 
mission 

type 
Wesruturee. | Oc 
yefuture.loc 


GOS. f 
Ta.c¢ou.error 
Sin. f 


update.cluster 


execution time and 


storace 





PARAMETERS 


NUMBER 


1de fo 
Name.priority 


mecAL VARIABLES ¢ 


a 
m 
priority 


GLOBAL VARIABLES ; 


WRITES : 


eeeerTeS ¢; 


maclsS : 


SeLLleD BY 


COMPLEXITY 


amteineClusters 
direction 
fomtaqt.rance 
missTon 
noecliusters 
Prly<cot cluster 
time.of.update 
xecurd 


a 
lant 0 
speed 
yY.ecur4 


mission 


) 


dist 


uodate.cluster 


: Constant 
requirements. 


NEW.MISSION 


Bites Olbveer CODE s: 14352 


m 
priority 


0 a le. 
name.oriority 


a 


clusters 
fist 

}count 
mSsnename 
pointing.to 
speed 
time.v 
yecurd 


direction 
msnename 
x ecur4d 


tracer 


execution time and 


storage 





OPEN.RADIO.NET 
NUMBER BYTES OBJECT CODE =: 240 


PARAMETERS 3: 
ida hadio 


LOCAL VARIABLES 3: 
id.radio 


GLOBAL VARIABLES : 
state3 


mrelS °: 
tracer 


SCHEDULED BY : 
artyeimpact commo.attempt 


end.ofemission guns.firing 


COMPLEXITY M Constant execution time and 
requirements. 


storage 





PARAMETERS 


e 
e 


3 


LOCAL VARIABLES : 


cS 
weaponry 


GLOBAL VARIABLES °¢ 


CALLS : 


BAELED BY 


BOMPLEXITY 


c¢.bar 
defnum 
d.num 
micro 
mvetime 
po.hat 
fol ie 
PeVv 
time.v 
Vems 
xect 
yect 
Zac 
zh 


move 


lor 


PARAM.SET 


NOMBER BYTES OBJECT CODE : 920 


> storage requirements 


constant. 
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aname 


bar 
diremvmt 
medet 
mine.det 
name 
piehat 
ollow. cond 
sod 

t.spd 
wonetyoe 
X-cUrT.enCe 
yecurrent 
zZzecurrent 


and execution time 





PARAMETERS 


NUMBER BYTES OBJECT CODE : 1128 
PARAMETERS 3: 
) k 
rg type.ammo 
LOCAL VARIABLES 2: 
count delta.l 
delta.2 fraction 
j j 
lk rg 
sig.df $1qQ.rgq 
GLOBAL VARIABLES : 
noerange.bdands range.bands 
MattS 3 
tracer 
meacLleD BY 3: 
assessment error 
COMPLEXITY : execution time 1s linear depending on 
number of range bands. Storage 1s constant. 
REMARKS : This routine returns the value of Sig.rg 


sig-edf to the calling routine. 
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the 


and 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


WRITES : 


BALLS ; 


BALEED BY 


SUOMPLEXITY 


VWwiieerworleES OBJECT CODE 


tnk 


BSED 3 
efkill 

jo 

tnk 
whocalled 


PASLES : 
damage.num 
defnum 
fired.at 
guntube 

k . rrt 

Mor 
minteth 
mkitl 
nease 
plow.econd 
sod 
won.etype 
yecurrent 


defnum 
fired.at 
guntube 
mio) © 

med 

mki ll 
nease 

sod 
won.type 
yecurrenct 


atrit 


POP.A.MINE 


$1760 


type 


emkill 
kaykill 
type 


4 


dam.array 

toa 

fkil] 

hit.state 

kki tl 
mfki ll 


name 
numehit 


time.v 
x.current 
zecurrent 


Wy ls, 

fea | 
hit.state 
kk il] 
mftkittl 
name 
Humeh tt 
time.v 
XeCurrent 
zecurrent 


convert.back 


¢ Storage 
constant. 


requirements and execution time 


1/77 





POSITION.UPDATE 


“NUMBER BYTES OBJECT CODE : 1104 


PARAMETERS °: 
a 


LOCAL VARIABLES 3 
a 
1demission 
tank 
yedar 


GLOBAL VARIABLES : 
b.eorgealive 
direction 
name 
red.alive 
speed 
time.v 
x.ecurrent 
yecurrent 


SaeeS 3: 
cos.f 
Sin. f 


GCOLEED BY : 
arty.impact 
new.location 


10.MiISSION 


elas 
sod.bar 
xebar 


¢-enumber.array 
fayset 

Moec busters 
sed 

stated 
t.position 
xecur4 

yecur4 


Loe 
tracer 


error 


COMPLEXITY : Storage requirements are constant. Execution 
linear on tanks in red.alive. 


eee: 





PREPLANNED 


NUMBER BYTES OBJECT CODE =: 1008 


PARAMETERS 3: 


3 b 
C d 
2 i 
LOCAL VARIABLES : 
a b 
Cc d 
a . 
1 “y 
K | 


GLOBAL VARIABLES 3: 
red.planned.fires 


CALLED BY °: 
faci. main 


COMPLEXITY : Constant execution time and 
requirements. 


PRINT 
WwMeerR BYTES OBJECT CODE : 356 


PARAMETERS: 
idem1ission 


BOeeAL VARIABLES ; 


deoug i1d.mission 
rad.err x.ecurd 
xefuture.loc yecurd 


yefuture.loc 


WRITES 
rad.err 


SAeeS 3: 
dist 


mawercD BY : 
artyeimopact assessment 


COMPLEXITY : Constant execution time and 
requirements. 


storage 


storage 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


WRITES : 


BAELED BY 


SOMPLEXITY 


NUMBER GYTES OBJECT CODE > 


1d.m1ission 


ABLES 3 

} 
1demission 
tank 


TABLES °: 
b.orgealive 
debug 

name 
rd.offset 
red.alive 
tank 

x. Current 
yecur4 


yefuture.loc 


1 

name 

xecurd 

xe future.loc 
yecurrent 


arty.imoact 


s Execution time 


and storage 


PRINT1 


is 
TS constant. 
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10.46 
J 


1124 


eenumber.array 


fist 
noecluster 


state4 
xecur4d 
xeruture. loc 
yecurrent 


J 

rd.offset 

x current 
yecur4 
YVerucure. ioc 


assessment 


linear on tank 


in 


red.alive 





PARAMETERS : 


PRIORITY .AND.ROUND.SELECT 


NUMBER Br tes OBJECT CODE : 13356 


a b 
LOCAL VARIABLES : 
3 answer 
'e j 
) p 
rnd threshold 
GLOBAL VARIABLES 3: Zz 
olue color 
dsl range 
wonetype 
BALLS : 
ammo.check t FuirmGert 


PelIBEED BY ; 


targqet.select 


COMPLEXITY : Constant execution time and 
requirements. 


REMARKS : Returns the value of 0 and rnd to the 


routine. 
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storage 


callina 





PROXIMITY DETECT 
_ NUMBER BYTES OBJECT CODE : 864 


PARAMETERS ; 


a b 

LOCAL VARIABLES : 
a b 
whocallea xesample 


yesamole 


GLOBAL VARIABLES : 


alive.dead blue 

eolor Bt 

plt.eunit tank 

Keeurren t yecurrent 
meee S 3 

abs. f list.uodate 


PaAeLEeD BY ; 
detect 


COMPLEXITY : Execution time is linear on tank mn 
and storage 1s constant. 


G2 


Sl tm 





RED.CREATE 
‘NUMBER BYTES OBJECT CODE =: 2408 


PARAMETERS 3: 
3 b 


LOCAL VARIABLES 3 
a b 
1 


GLOBAL VARIAS8LES : 


apetow - array.detect 
bbbpoint bewcounit 

bn benum.alive 
cenumber.array co 

eecur defnum 
dir.ofemvmt Lest 
max.enumber.of.missions.per.fo 
mvestate name 

Abst op .erng 

ie Gc op low.cond 
ott oleldr 
pointer Of. c1..t 

sod tank 

target time.v 
won.etype xecurrent 


yecurrent 


READS 3 
on co 
Gocer name 
roi ; Srtior 
won.type ¥.-curPent 
yecurrent 

meeAtieS : 
tank 

MILES 3: 


tank in tanks, red.aliver comp.unit and plt.unit 


RESERVES : 
array.detect c enumber.arfray 
list 


Bas 





RED.CREATE (cont.) 


meee ASES : 
array.detect cenumber.arfray 


BALLS ;: 
basic.load hider 
set.sector 


MALLED BY : 
new.forces 


BCHEDULES ;: 
loc.uodate 


COMPLEXITY : Execution is dependent on input parameters a 
and ber main loop will be executed be-atl times per 
invocation. Storage 1s dependent on obc.count, 
n.fo and max.number.of.missions.per.fo. 


184 





PARAMETERS 


RED .ARTY.FIRES 


NUMBER BYTES CBJECT CODE : 3368 


id.-red.btry 


LOCAL VARIABLES : 


j 
iteration 
redececonstant 
x 


GLOBAL VARIABLES 3: 


alive.dead 
blue.alive 
defnum. 
fired.at 

foe 

hit.state 
kkill 

md 

mkil] 

ncase 
noemsns.fired 
Num.e guns 
numehit 
red.planned.fires 
salvos 

tank 

wonetype 

y current 


“ 


caliber 
fo 

fkill 
hit.state 
kKkill 
mfkill 
name 
numehit 
timeev 
xecurrent 
z2.e-current 


iteration 


id.red.otry 
Ok 
type.ammo 


4 


arty.pk.table 
caliber 

1 ie! 

yee EL 

guntube 

cant 

kount 

mfkil1] 

name 


num.edoicm.left 
MUM. fh ea lea t 


ra.stream 
spd 
time.v 
xecurrent 
Z2ecurrent 


defnum 
fired.at 
auntube 
erent 

Med 

mkil 
ncease 

spd 
type.ammo 
yecurrent 





meaclS : 


SCHEDULES 


SCHEDULED 


Some LEXITY 


REDGARTYsrIReS Ccont) 


atrit loc 
tracer uniform. f 


red.arty.fires 


By <$ 
faecemain red.arty.fires 
: Storage requirement is constant. Execution time 


is deoendent on the product of salvos and tanks in 
blue.alive. 
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RELOAD 
WNeorween orves OSJECT CODE : 2736 


PARAMETERS 3: 
a 


LOCAL VARIABLES :; 
a 


GLOBAL VARIABLES 3: 


btime fees) 

Cn . capds 

case eoqa 

Cdn ecdtime 

cheat Cit 

defnum def.time 

guntube Vmat 

P.Gon si.time 

S2.time veh.typoe 
Peeuco) BY : 

hide 


SeeebULES : 
hide 


COMPLEXITY : Constant execution time and 
requirements. 


RES1 
NUMBERS BYTES OBJECY CODE : 232 


” 


GLOBAL VARIABLES 3: 


hnorm norseed 
READS 3 

norseed 
RESERVES : 

hnorm norseed 


SeeeeD BY : 
main 


COMPLEXITY : Constant execution time and 
requirements. 


ey 


storage 


storage 





RES 
NUMBER BYTES ORJECT CODE : 2000 


GLOBAL VARIABLES : 


accom accht 
accke accms] 
addon bm.mov 
bushbomp dgnv 
ht .mov ke.emov 
lell lele 
le3l leol 
le71i le7e2 
le8l -1e8e2 
minleth sovma 
tardim usmg 
MEOERVES 3: 

accbm accht 
accke accms] 
addon om.emov 
bushomoe dgnv 
ht mov ke.emov 
lell lele 
le3l le6l 
le71 le72 
lel 1e83 
minleth sOVvmMG 
tardim usmg 


Paeeep BY : 
main 


COMPLEXITY % Constant execution time and Storage 
requirements. 


REMARKS :; Rearrangement of subscripts will provide more 
efficient storage utilizing fewer pointers. 
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RES3 
NUMBER BYTES OBJECT CODE : 3336 
LOCAL VARIABLES : 
i j 
k 


m 


GLOBAL VARIABLES : 


lell lete 
le3i leél 
le7i _ Vee 
le8} ,1e83 
CALLED BY : 
main 
COMPLEXITY : Constant execution time and storage 


requirements. 


REMARKS : Rearranging looms to avoid duplication will Cut 
the number of "for™ looos from 1lil to 6. 


RESG 
NUMBER BYTES OBJECT CODE : 1912 
LOCAL VARIABLES : 
j j 
k 1 


m 


GLOBAL VARIABLES 


ee 


accht accke 
accms | addon 
daqnv ht.mov 
Ke.emov tardim 


MeELED BY 3: 
main 


COMPLEXITY : Constant execution time and Storage 
requirements. 


MerARKS $$; Combine 7 “*for“ looos with i=! to 2 into 1 loop. 


eos) 





BAELED BY 


REMARKS 3 


PARAMETERS 


mai 


Thi 


Reso 


NUMBER BYTES OBJECT CODE 


Nn 
S routine does nothing. 
SEC TOR SeHECK 


NUMBER BYTES OBJECT CODE 


LOCAL VARIABLES ; 


GLOBAL VARIABLES : 


SaAELS : 


CALLED BY 


Some eEXITY 


PARAMETERS 


3 b 

a answer 

b Cc. heft 

C irmargin't r 

ee Vet 

area constant 
xeCurrent yecurrent 
abs.f sart.f 
impact steop.time 


3 


e 
* 


48 


608 


Constant storaae and execution time. 


” 


See UZ ees VEL 


NUMBER BYTES OBJECT CODE 


LOCAL VARIABLES : 


S| 


GLOBAL VARIABLES : 


CALLED BY 


COMPLEXITY 


mz | 


evel 


fire 


e 
a 


400 


Constant storage and execution time. 


P70 





“te, 


Sewer OR 
NUMBER BYTES OBJECT CODE : 448 


PARAMETERS : 
tank 


LOCAL VARIABLES : 


3 b 
tank width 
x y 


GLOBAL VARIABLES : : 
Opec , 


mactS 3: 
cos.f Sim. f 


CALLED BY ;: 
chg.sec.search defend 
dismount.dragon main 
red.create 


COMPLEXITY : Constant storage and execution time. 
SIGHT 
NUMBER eYTES OBJECT CODE : 7i2 
PARAMETERS : 
3 aname 


b oname 


GLOBAL VARIABLES 3: 


bwd.look fwd.look 
nite micro 
name opca.eunc 
pca.evis Bieoeunc 
pcb.evis xecurrent 
yecurrent zecurrent 
SACLS ;: 
los min. f 


Peerel BY ; 


commo.pass.tgt detect 
fire impact 
step.etime target.select 


MemremexilY : Constant storage and execution time. 
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Sse =) he 
-NUMBER BYTES OBJECT CODE : 1664 


PARAMETERS 3: 
3 


LOCAL VARIABLES 3: 


F) answer 
bdet.time lose 
r rdet.time 
Gn. © eile tf 
GLOBAL VARIABLES °: 4 
alive.dead answer 
bwd.look defnum 
delta.t . to 
fmbiviesalive fwd.look 
name op.rng 
pebeunc pet<vis 
steos target 
tgtscl time.yv 
WieK eC Cecursi.ent 


yeCurrent 


RESERVES 3: 


bist 

REEEASES ?: 
list 

GAELS ; 
cardio chg.sec.search 
Gist al es 
Sector.check sight 
tracer uniform. f 


SenaeDULES : 
detect step.time 


BemeDULED BY 3 
main step.time 


COMPLEXITY : Storage is constant. Execution time is linearly 
dependent on the number of tanks in red.alive. 


92 





.NUMBER BYTES OBJECT CODE : 


GLOBAL VARIABLES :; 


attributes 
attributes 
attributes 
attributes 
attributes 
alive.dead 
awl.or.ms] 3 
bce ecount 
Chet 

co 

defnum 

tad 
fired.at 
he.drag 

k hit 

lia 

med 

mf.ehit 

mk il] 

name 
n.olue.alive 
Numehit 

olt 

Recon 

sec 

sod 

time.v 
{sod 
Xecurrenc 
zecurrent 


STOP.SIMULATION 


every 
every 
every 
every 
every 


fo 


4296 


oattery 


tdc 


mission 
mission 


5 


In msn.queue 

in holding.emsns 
ap.tow 

on 


‘Cac 


Cnt 

Gir.eof .mvmt 
fon © 

fkil] 
hit.state 
kkid 


mehit 
mfkildl 
mvestate 
Ad.hit 
nered.alive 
Dlow.cond 
ori.dir 

eG GOUNTt 


tank 

tet 
won.tyoe 
yecurrent 





WRITES 3: 
attributes of 
attributes of 
attributes of 
attributes of 
attributes of 
alive.dead 
awl.eor.msl 3 
bcecount 
Gis 
(exo 
defnum 
eee 
fired.at 
he.drag 
kehit 
lin 
mM <i 
sci 
mk il) 
name 
n.blue.alive 
numehit 
pit 
recon 
sec 
sod 
time.v 
t.sod 
x,current 
z2ecurrent 


GAELS $s 
loc 


Sem@eDULED BY ; 


STOP.SIMULATION (Cecont) 


every 
every 
every 
every 
every 


attrition.check 


COMPLEXITY : Execution time 


is constant. 


is 


fo 
battery 
fdc 
mission 
mission 


iN msn.equeue 
in holdingemsns 


ap.tow 


bn 


Cw 
Be as 


direor.mvmt 
font 

ee 
hitestate 
kKkil] 


mehit 
mfki]] 
mveState 
aol sinh his 
nered.alive 
Dlow.cond 
ep nee 
reecount 


tank 


tre 


wonet yoe 
yecurrent 


main 


linear on tanks and 
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storage 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


CALLED BY 


SOMPLEXITY 


NUMBER BYTES OBJECT CODE : 


3 


ABIES : 
3a 


PABIES : 
olue 

Oro jo 
sod 
t.sod 


fire 


: Constant 
requirements. 


SUG ReOer TRE . 


execution 


1S 


368 


stopcount 


stopcount 


igor 
second.shot 


“‘timeev 


imoact 


time and 


storage 


a 





SUBCAL 
‘NUMBER BYTES OBJECT CODE : 4040 


PARAMETERS : 


f.pcvis OC.eVIS 
c sh.t 
ait. C 

LOCAL VARIABLES 3: 
efkill efol 
emkil] emp | 
f.pcvis 7 
io 5 
Jo Kane 11 
Kayo! ] 
mo n 
nhit SG 1S 
phit r 
ro She 
Cae. € vel 


whocalled 


GLOBAL VARIABLES : 


bushbmp damage.num 

dgnv oh 

projo sOovma 

sod tardim 

usmg won.tyoe 
WRITES : 

projo won.type 
CAiseS : ‘. 

binomial. f bushomp 

sovmg thilaG. ft 

usmg 


CALLED BY : 
compute 


COMPLEXITY $: Execution time is linear on nhit and storage is 
constant. 


yo6 





iyecrACTICS 
NUMemerR BYTES OBGECT CODE =: Lele 


PARAMETERS ¢: 
a 


LOCAL VARIABLES ; 


a aim 
answer lose 
result time 


x 


GLOBAL VARIABLES : 


alive.dead bwd. look 
check.time cocar 
critical.value foe 
twice ook Bet. v1sS 
oltidr projo 
sched - Yank 
time.a time.v 
eats ¢$ 
ammo.echeck commo.pass.tgt 
expo. f lay.~loaa 
loc 


meee) BY : 
target.select 


SemenDuUlLES ; 
fire 


COMPLEXITY : Execution time is linear on tank in plt.unit 
and storage requirements are constant. 


REMARKS : Returns the value of answer to the calling 
routine. By initializing answer to 1 instead of 
QO, two “if"™ sequences may be eliminateaq resultina 
in ll fewer lines of source code. 


or 





TALLY.HIT.STATE 


‘NUMBER BYTES OBJECT CODE 3; 


PARAMETERS 3: 
damageenum 


LOCAL VARIABLES : 
damage.num 


GLOBAL VARIABLES : 
blue 
co 
comp.untt 
t Shivt 
cenit 
m,.olue.alive 
Mmemit 
Nnoehit 
pit 
red.alive 


REMOVES 3 
tank from blue.alive or 
comoeunit 


Ree AGES °¢ 
list 


Crees ¢$ 
leave.check 


meeeeD BY ;: . 
final.death 


COMPLEXITY : Constant 
requirements. 


aS 


execution 


1856 


tank 


tank 


blue.alive 
color 


fired.at 
list 
Mien tt 
name 
MUmMena t 
Slt. un t 
target 


red.alive, Set wun we and 
Impact 
time and storage 





PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


Cnet S ° 


See DULES 


SCHEDULED 


Bee LEXITY 


TARGET.SELECT . 


‘NUMBER BYTES OBJECT CODE :; 


a 


ABEES: 3 

a 

answer 

’ 
old.range 
fe 

rnd 
whocalled 


Peewee Ss. 
alive.dead 
bwd.look 
color 
defnum 
f1c 

feild) 
fwd.look 
list 

name 
pointer 
range 
target 
time.v 
XxeCcurrent 


omp.tactics 

dist 

hider 

1tvatac ties 

list.update 
priority.and.round.select 
trestactics 


fire 


oe ae 
list.update 
weemiss 


blue 
check.time 


ceritical.value 


foe 


lyme.or-siaqht.exists 


mv.eSstate 
pctevis 
DrFOjO 
sched 
time.a 
won.etypoe 
yecurrent 


1m af 

@xiD . f 
ifvetactics 
lay.eload 
hoe 

Sight 
xmi.etactics 


we.ehit 


>: Constant storage and execution time. 


Ae, 


2o9e 





TRACER 


NUMBER BYTES OBJECT CODE : 304 
PARAMETERS s$ 
a 


LOCAL VARIABLES ; 
cs 


GLOBAL VARIABLES : 
timeev tr.etime 


WRITES ¢: : 
a tcime.v 


BpeeeeD BY ; 
arty.eimpact arty.time 
busyefradio.net 
checking.-gunS.availaoility 


commo.attempt detect 
end.of.mission error 
fa.tgt.error fde.processing 
fy he auns.firina 
impact mrl.eimoact 
new.coordinate.system newelocation 
new.emission open.radio.net 
Darameters position.uodate 
red.arty.fires stepo.time 


uodate.cluster 


COMPLEXITY : Constant storage and execution time. 
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UPDATE.CLUSTER 
NUMBER BYTES OBJECT CODE : 2256 


PARAMETERS : 


1 (@) Glgte, 

LOCAL VARIABLES 
estimate.of.time Wel 6 ake) 
1d.m1ission m 
NMame.priority prievalue 
time.l time.c 

GLOBAL VARIABLES : a 
amt.activeemsns amt.emsns.fired 
busy debug 
last.eclustered msnetime 
maxenumber.of.emissions.perefo 
stated time.v 

WRITES : 
1d 10 time.v 

Gaels : 
arty.etime doing.eclusters 
new.location newemission 
tracer 


Sem@eDULED BY s 
faecemain fo.not.busy 


COMPLEXITY : Constant storage and execution time 
; VALS.FOR.CASE 
NUMBER BYTES OBJECT CODE : 7le 


GLOBAL VARIABLES 


ba bh 
capds case 
caseap casehe 
cda cdh 
cheat Quntube 
nit 


Beeeeh BY 3: 


main 


COMPLEXITY : Constant storage and execution time. 


e0l 





WE.HIT 
NEMBER=™BYIEs OBJECT CODE : 1328 


PARAMETERS 3 
3 


LOCAL VARIABLES 3: 
3 


GLOBAL VARIABLES : 


ap.etow awi.or.ems] 3 
awe.or.adm Gre 
eee defnum 
foe he.drag 
hitshot missshot 
recon rec Olt 
won.etype 

GAELS ; 
hider 


SaeeeD BY ;: 
impact 


SemeBPULES s 
hide target.select 


COMPLEXITY : Constant storage and execution time. 
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PARAMETERS 


LOCAL VARI 


GLOBAL VAR 


SaLLS $ 


meee eD BY 


SCHEDULES 


BOMPLEXITY 


WE.MISS 


NUMBER BYTES OBJECT CODE =: 1808 


a 


ABLES < 
a 
e 
x 


PABeeES § 
apetow 
awce.or.adm 
Cee 
defnum 
he.drag 
missshot 
range 
sched 
timeev 
xecurrent 


ammo.echneck 
exp. f 
lay.load 


Imoact 


fire. 


target.select 


answer 
time 


awl.eor.ms} 3 
Ca 
check.time 
foe 

hitshot 
olf te) five 

recon 
time.a 
wonetyproe 
yecurrent 


dist 
hider 


hide 


: Constant storage and execution time. 
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XM1.TACTICS 
NUMGER = bY Neo CGJECT CODE <= 35e 


PARAMETERS : 
3 b 


LOCAL VARIABLES :; 


3 answer 
b Z 
GLOBAL VARIABLES °: 
foe Sk 
olt.unit tank 7, 


malts °: 
uniform. f 


MeetLeD BY 3: 
target.select 


MOMPLEXITY : Storage is constant. Execution is linearly 
dependent on the number of tanks tin oplt.unit. 
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ROUTINE 


main 

hider 

resl 

rese 

res 

res4 

resS 
red.create 
bl.create 
new.forces 
sight 
convert .back 
param.set 
basic.load 
vals.for.case 
reload 
bugecheck 
dremount 
dismount.dragon 
df.chag 
defend 


step.time 


APPENDIX C 


LINES START 


SIMOCRITPT ROUTINES 


95 ba028 
LO) OO 750 
3 bb890 
24 bb978 
57 be 148 
e{S. bce50 
2 bdSc8 
43 Didianac 
46 bdf60 
= beab8 
7 bebes 
17 beed0 
el bf178 
e7 bf510 
10 Dinas 6 
40 c0000 
2 c0ab0 
18 c0ebd0 
le ers a4 
14 c1640 
V2 E1350 
65 claed 
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END 


bbo750 
bb890 
bo978 
be l48 
beeS0 
Sdecd 
bdSf8 
bdf60 
bea6s 
bebe®é 
beeb 0 
bf178 
pay 
bfd38 
c0000 
cQab0 
c0eb0 
21358 
c1640 
e1a5 0 
clae0 


c¢2660 


Siehaie 


320 


E52 


2000 


$336 


Oiled 


48 


2408 


elaett) 


ee 


(lye 


(oie 


ie) 


2088 


alee 


2746 


1024 


ete 


744 


496 


688 


1664 





ROUTINE 


detect 

target.select 

fire 

leave.check 

charge 

get.uo 

impact 

loc.update 
stop.simulation 

cardio 

list.update 
proximity.detect 
commo.pass.tgt 

emt actics 

mve tactics - 
xmi.tactics 
bmp.tactics 
itvetactics 
set .muzzle.vel 
priority.and.round.select 
ammo.check 

gdecrement.ammo 

weemiss 

weehit 

S@op.to.fire 


lay.eload 


21 


en 
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START 





ROUTINE 


loc 
chg.sec.search 
tally.hit.state 
Gist 

set.sector 
sector.echeck 
attrition.check 
compute 

geom 

sudcal 

atrit 
pop.a.mine 
final.death 
faeil.main 
faec.main 
fo.enot.busy 
update.cluster 
commo.eattemoet 
open.radio.net 
busy.radio.net 
fdc.processing 
checkingequns.availability 
guns.firing 


arty.imoact 


46 


ome) 


les 
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START 





ROUTINE 


end.eofemission 
doingeclusters 
assessment 
error 


red.arty.fires 


new.coordinate.system 


newemission 
parameters 
arty.time 
faetgt.error 
newelocation 
mel.eimpact 
preplanned 
position.update 
print 

printl 
tracer 


new.fo 


move 
initrd 
setup 
los 
kover 
elev 


aytunx 


a 


START 


9550 


dadseQ 


db998 


dcb48éa 


deef& 


ddc20 
ddd18 
decb0 
de/18 
de&b8 
dea58 
defcd0 
Gi2ce 
dfdb8 
e0208 
e0358 
e0840 


e0970 


FORTRAN ROUTINES 


145 


es) 


SS 


as! 


14 


8 


Sl 
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e4c88 
eQels 
e70b8 
e5260 
eecc) 
ecead 


efal8 


END 


daSe0 
db998 
dcb48 
deef8 
dacce 
ddd18 
deeb0 
de/18 
de8b8 
dea5é@ 
defc0 
df9c8 
dfdb8 
e0208 
e0358 
e0840 
e0970 


e0b38 


e5860 
e1688 
e/508 
e4c88 
ee3f0 
e3iad 


efaad 


1384 
220e 
1008 
1104 

556 
lied 

304 


456 


4048 
e414 
1300 
7504 
684 
988 


his3 





ROUTINE 


elevg 


mcov 


LINES SJART 


38 eebeS 


24 ecb88a 


PROGRAM TOTALS 


3842 ba02c8 


a 
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eef 78 113e 
ecdd8 866 
1177e0 382904 





APPENDIX D 


ROUTINE IYEGe WDS PTRS OPT REMARK TOTAL OPTIMAL 
dgnv i 16 3 Ste) 19 19 
usmaq i 48 16 16 (*/2) 64 64 
sOovmg i 96 33 poor 27 2) eo 2g 
bushbmp i reg 47 47 (*/2) | ae) a5 
accms|] r eeu Sp 23 Ca eu, 
keemov r 420 83 39 505 4s9 
accke r les Su ss eug ol yf 
ht emov r 420 83 39 SS 459 
accht . 224 67 25 291 247 
addon P 80 if 7 87 a7 
accbm r 84 a5 9 109 WS 
bmemov r 210 4 | 19 eo ee? 
tardim r 198 10 ae 208 208 
hnorm re) 1000 1 1 1001 1001 
norseed ec 2 1 0 S . 2 
minlteth i 5 10 9 Nes: 14 
peeeacd.error r le S 5 es es 
tgtsc] r 18 l l 19 19 
mu r 24 3 5 roa | eat | 
xect . 2 1 0 S 2 
vee t r e 1 0 3 2 
Zact r eC 1 0 3 2 
Vems 2 1 0 5 2 
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ROUTINE 


pcaevis 
pebd.unc 
pcbd.vis 
pca.unc 
Dev 

zh 

list 


target 


temp.target 


dsl 

ase 
t.dead 
1.dead 
1t.dead 
heal 
le/7i 
lele 
le7e 
le3l 


leol 


210 


£210 


PUR S 


Bee 


ow 


OPT REMARK 


(x/4) 
(x/4) 
(*/4) 
(*/4) 
(*/4) 
(*/4) 
(*/4) 
(*/4) 


(x/Q4) 


TOTAL OPTIMAL 


SITE 


siv7 


294 


294 





ROUTINE irre SUS PTRS OPT REMARK TOTAL OPTIMAL 


1e8l 1 Se 416 249 = *®/4) 944 774 


1e83 i Bae 416 249 (*®/4) 944 774 


eave 
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